Make your MVP in whatever language you know best.
Don't chase after buzzwords or trends.
I personally use PHP, mySQL and Redis with nginx proxy, cause I know these the best.
Probably nodejs would be a bit faster, but then again, I would probably make 100s of mistakes, not to mention god knows how many bugs, because I'm not 100% familiar with the language.
Just deployed a lambda script that spins up a FreeBSD ec2 image that checks out, compiles, and runs the contents of a dynamically provided git url, with dynamically specified pkg and pip dependencies to make my own long-running FreeBSD-based lambda-esque service for some continuous deployment.
Wouldn’t have been possible without the ec2 images and the configinit magic.
I guess so. It seems strange to me that anyone would want to inflict upon themselves the pain of using different environments for development vs. production, though.
You'd think so, but I bet a large portion of developers on hacker news develop on a mac and run their apps in production on a linux distro. At least for web apps.
Could be. I know a lot of Mac owners who only ever do three things directly in OS X though: Run a web browser, use video conferencing software, and launch linux and BSD virtual machines.
Haskell & Elm. Deployed to AWS with NixOps. Persisted with PosgreSQL and Redis. Code hosted in either Bitbucket or GitHbub. Tasks managed with Trello and email. Occasional sync meetings over appear.in or Zoom (I travel).
NixOps supposedly supports several hosting providers, but the DigitalOcean integration is currently broken. AWS works great, but it's annoying to be forced into that choice by the tool.
Haskell and Elm both work great, but I can imagine in future using something like Haste or PureScript Bridge; it'd be nice to work with both the backend and UI as a single project. Not a pain currently, but this is a nice to have.
Biggest pain is documentation. Haskell stuff is documented, but more hand-holdy examples would be ideal. OTOH, some language communities have a culture of writing documentation that is too hand-holdy, flooded with emojis, and is generally frustratingly infantilising. I'd like Haskell to strike a balance between the two. I'm optimistic we'll get there eventually.
Nope. Not in any of the several products I've put in production with Elm. There have been times when I've needed more things than Elm provides — one time I needed a library for parsing a streaming JSON response — but the JS interop through ports works just fine.
Started with Python + Django + MySQL, hosted on PythonAnywhere.
At some point, decided to rewrite the project from scratch in Clojure using MongoDB, since Clojure was much better suited for solving the problem in question (modelling the grammar of a natural language - https://www.pealim.com) and MongoDB was better suited for the constantly evolving grammar spec. The rewrite took around two months and I believe that it was the right decision, though I still miss some of the things that Django provides for free (like the admin interface and user authentication).
I also use ClojureScript + Reagent, though not yet on the user-facing parts of the app.
pealim.com is my most visited site (according to the chrome home screen). I could not have learned עברית so quickly the last couple of years without it. תודה רבה!!!
We [1] use a Laravel back-end for the main system, hosted on autoscaling EC2 behind a load balancer.
Our front-end web application is built on Angular, running on S3 behind CloudFront.
Since we process a lot of data, we use background jobs (with SQS as a broker) to perform our analyses.
The actual data processing and wrangling is done in Python.
We have released some parts of our systems as open source projects [2], [3], [4].
I agree! Lumen is my go-to framework for small web-based things right now, picking things from Laravel is so powerful.
1) At the time, Python (and with it pandas/numpy) seemed to be a good fit for the data we were working with (and the analysis was developed as a separate project from the main system that calls it). If we were to do it over right now (and we well might in the coming months) we would probably move this into PHP as well, which makes writing workers much easier.
2) Cost-wise, SQS makes a lot of sense - the system is highly distributed and cut up into parts (the description in my first comment is a bit simplified) so adding redis to the mix means adding a whole new server. For SQS, we're just paying per-message (and we don't have a _lot_ of messages, so it's cheap).
Furthermore, I've built an algorithm to scale up the background workers based on the queue size of SQS. This runs in Lambda, which makes it super easy to access SQS properties versus connecting to a remote redis server. Basically, the algorithm rents new EC2 instances whenever the load is high and terminates them whenever the load is low.
We sell diagramming libraries, most notably (by sales volume) a JavaScript diagramming library: https://gojs.net
Our stack is: we don't care. One of us spun up a couple AWS resources and a windows machine with IIS because that's what he knew how to configure the quickest. It seems like it would be a waste of time to spend any more time thinking about it until we have a real need.
We have some orders database stuff we wrote ourselves ages ago with SQL Server that hasn't needed significant changes in 10+ years.
In other words, to us, the stack is whatever makes itself disappear the soonest so we can work on the actual product. Nothing fancy, nothing new, nothing changed for the sake of it.
If our product touched the stack more, we'd spend more time on it, but only insomuch as it was the product (if the product is a speedy website, etc).
Our workflow/cycle is all JavaScript based for the JS product. We push release with a gulp script I wrote.
As an indie founder, I prefer to use Node/Express and React/Redux, hosted on Digital Ocean. Really fast and convenient to build SaaSes and single page apps like:
:P I still write orchestral music with Cubase on a 1999 IBM PC running Windows ME. Writing this comment on my new (2005) computer with OmniWeb browser, os x 10.4. Hmm maybe I should be in healthcare.
We're not exactly a startup, but a small growing data science, analyst, and engineering team in a bigger company. You name it... but a typical data and web stack.
All running in AWS deployed through CloudFormation and Salt.
There's even a Windows Server 2016 instance thrown in there for good measure running Tableau. That's the most reliable part of our stack. </rolls-eyes>
Node.js/GraphQL/Next.js/PostgreSQL/AWS Lambada (via up). Entirely serverless stack with the application state residing in the DB and a JWT to identify the user. No OS, containers, kubernetes, instances, etc to deal with other than a single RDS instance.
We mostly use docker with docker swarm. Currently exploring moving to Rancher. Also we use Gitlab CI for CI/CD. Our workflow looks like this: a release is tagged, CI tests and builds a docker image which is pushed to our private registry and then we use ansible to deploy the new release on our servers. We mostly use onprem for our production and can't use any cloud with the regulations and limitations we have.
I have not personally been involved with a lot of the development for the past couple of years. I could ask a colleague. Send me an email - james@blitzm.com
Webapp2 or something else? :) It's been so long I've seen someone use python on GAE, it's ridiculous. It was my first ever "real world" programming project back in 2011.
Plain Ruby + Sinatra+ Puma + MySQL (ConnectionPool) + Sidekiq on Redis for the back-end. Sinatra/ERB for low-traffic sites, and ReactJS on S3 for more traffic on the front-end. I always like to err on the side of common denominator, rather than adding as many 'currently hip' tools as possible. Every time I try new things, it eventually brings me back to this set of tools.
For anyone here interested, there's a website that has a nice UX for this: https://stackshare.io/
What I like about it is you can add open source projects to your stack, not just SAAS services. And also, you can split your server-side stack from your personal tools.
Meteor + React + MongoDB got eddtor.com really quick out of the door. But after 5+ years of maintaining my shipped products (I'm a freelancer, ME-JUST-ME kind of dev), my absolute happiness in customer service & maintanance was the most boring stack of all: PHP + HTML + JS + MySQL/MongoDB. Vanilla FTW.
Not the greatest fan of Azure, mainly because of the admin portal, but apart from that it's been good.
Constantly get told by their clients that we do everything much faster than other SASS providers they work with, like weeks where others have turn arounds of months.
I don't use an ORM currently, just plain 'ol SQL queries. And in actuality I prefer it SOO much more. Like originally I was using Hibernate with the Java JPA, but I found it just got in the way a lot and the dependencies where finicky. Where as in Go and raw SQL I know EXACTLY what it's asking for and can pre-compose my queries externally. Any changes to the tables I have to make, as in renaming or adding columns, is just a quick change to the SQL query itself. And if needed, 1 line added to the Struct definition.
Also I'm more of a custom approach person which makes me very productive with Go. It's allows me to have laser focus on my needs instead of hooking up and reading docs and every little integration feature the framework has. And in result, I don't have dependency on a monolithic framework which could very well break everything in it's next release.
And finally, Go will build to binary for any-platform. So I can pre-build for the ARM processors, or Linux, or whatever else on Windows and just ship the binaries for server updates instead of managing make scripts and dependency resolution and blah blah blah. And if I wanted to I could sell the API "program" and sleep a little better about the IP contained in it (yes I know de-compilers exist). I could do this with C++ as well, but that's a whole 'nother ball game when it comes to tracking down memory leaks and segfaults.
Go optimizes for readability and lack of surprise at the expense of conciseness, which is why you feel it may not be productive. I think that the better maintainability vs. something like Rails massively outweighs the upfront cost of having to type more code, but other people might judge differently.
Furthermore, Go emphasizes "doing it your own way". There are no big web frameworks in Go, you just pull in some small and rather orthogonal libraries and make up your own abstractions to tie them together as you build your application. The end result is something that's highly optimized for your personal needs, but it requires a certain way of thinking and working that's not for everyone (and not always desirable). Some people do better when given more freedom; those should prefer Go etc. Some people do better when working within a well-known set of rules; those should prefer Rails etc.
Regarding ORM, I use Gorp (https://github.com/go-gorp/gorp) for INSERT, UPDATE, DELETE and basic SELECTs (e.g `SELECT * FROM things WHERE id = $1`), but when doing complex reports, I write SQL by hand [1] because ORMs are usually too constrained. I always feel like I know more SQL than the people who designed the ORM.
I'm struggling to think of instances where you would want to rename a column without changing the behavior of the column. The latter would mean that you have to review those 50 places anyway.
Gorilla Mux isn't bad either and is pretty tried and tested.
Also Go is one of the few (if not only?) languages with HTTP/2 built in to the standard library. Not to mention the gRPC over TLS that comes stock as well.
I have never created an apps or worked with React Native before. But, I would share the experience from my colleague who develops Android apps in our startup.
We are a startup that helps people in the middle-low income using technology. The people who use our technology usually have Android mobile phone with minimum specifications (Jelly Beans, low memory and spaces). At first launch, we used Android Native to build our application. The application meets our costumer needs since we consider to build an apps that consumes low memory and spaces. Then our costumer are growing and the features are complex, we use React Native to existing native app. Our application now consumes memory and spaces two times than Native one. Beside that, sometimes when you use a library, Native is more stable than React Native.
Rust on Linux with Cassandra, the strong typing without a GC is a boon to stability and performance (my own sanity). Cassandra is fantastic, looking forward to using Scylla at some point.
Ads (matching, serving, recording analytics), Scylla uses the same protocol Cassandra does. I've been using the CDRS crate which is pretty nice. It has a few rough spots that I've started to smooth over and send PRs for when I get a chance.
As a data company specialized in real time statistics for combat sports, we've built an API with Node.js + Hapi and MySQL. The front-end was developed with Vue.js.
My company is well over that number. I probably only know about a quarter of the stacks... And even within those, there is a lot of variation. There are java heavy stacks, python heavy stacks, nodejs, Ruby. Lots of systems level stuff in C, C++, Java. I can't even speak to any front end frameworks (although I know there are at least a few). Almost every other application you could think of is in use somewhere... Nagiod, Sensu, Icinga, OpenNMS, memcached, redis, nginx, Apache, redshift, MySQL, postgresql, rabbitmq, zeromq, Ansible, Chef... This is likely barely scratching the surface.
Seconded. I use it with the go-bindata backend and Postgres driver. Some notes:
- Migrations are written in plain SQL, so there may be portability issues if you need to support multiple DBs. (Or you need to write the same migration once per supported SQL dialect.)
Make your MVP in whatever language you know best. Don't chase after buzzwords or trends.
I personally use PHP, mySQL and Redis with nginx proxy, cause I know these the best.
Probably nodejs would be a bit faster, but then again, I would probably make 100s of mistakes, not to mention god knows how many bugs, because I'm not 100% familiar with the language.
C on FreeBSD on EC2.
Yes, the dynamic parts of the Tarsnap website are written in C.
Thanks for your work on the ec2 AMIs.
Just deployed a lambda script that spins up a FreeBSD ec2 image that checks out, compiles, and runs the contents of a dynamically provided git url, with dynamically specified pkg and pip dependencies to make my own long-running FreeBSD-based lambda-esque service for some continuous deployment.
Wouldn’t have been possible without the ec2 images and the configinit magic.
-mqudsi@neosmart
Awesome! Have you considered writing something about this setup? I'm sure a lot of people would be interested in hearing more.
Good idea! Hopefully will get around to doing so sooner rather than later :)
Interesting. What are the main advantages for you to use FreeBSD over Linux?
https://www.freebsdfoundation.org/blog/faces-of-freebsd-coli...
tldr cperciva is a long time BSD guy...
Which OS do you use for development?
It's a fair question. Many people use FreeBSD just for servers and use other distros for their workstations.
I guess so. It seems strange to me that anyone would want to inflict upon themselves the pain of using different environments for development vs. production, though.
You'd think so, but I bet a large portion of developers on hacker news develop on a mac and run their apps in production on a linux distro. At least for web apps.
Could be. I know a lot of Mac owners who only ever do three things directly in OS X though: Run a web browser, use video conferencing software, and launch linux and BSD virtual machines.
Umm... FreeBSD?
Haskell & Elm. Deployed to AWS with NixOps. Persisted with PosgreSQL and Redis. Code hosted in either Bitbucket or GitHbub. Tasks managed with Trello and email. Occasional sync meetings over appear.in or Zoom (I travel).
This is my favourite stack here by far. What are your pain points?
NixOps supposedly supports several hosting providers, but the DigitalOcean integration is currently broken. AWS works great, but it's annoying to be forced into that choice by the tool.
Haskell and Elm both work great, but I can imagine in future using something like Haste or PureScript Bridge; it'd be nice to work with both the backend and UI as a single project. Not a pain currently, but this is a nice to have.
Biggest pain is documentation. Haskell stuff is documented, but more hand-holdy examples would be ideal. OTOH, some language communities have a culture of writing documentation that is too hand-holdy, flooded with emojis, and is generally frustratingly infantilising. I'd like Haskell to strike a balance between the two. I'm optimistic we'll get there eventually.
Have you run into design decision limitations with Elm yet?
Nope. Not in any of the several products I've put in production with Elm. There have been times when I've needed more things than Elm provides — one time I needed a library for parsing a streaming JSON response — but the JS interop through ports works just fine.
You might find some interesting answers at https://stackshare.io/stacks
Stackshare is more informative than a majority of the replies in this thread that aren't stating their startup's name or use case.
Started with Python + Django + MySQL, hosted on PythonAnywhere.
At some point, decided to rewrite the project from scratch in Clojure using MongoDB, since Clojure was much better suited for solving the problem in question (modelling the grammar of a natural language - https://www.pealim.com) and MongoDB was better suited for the constantly evolving grammar spec. The rewrite took around two months and I believe that it was the right decision, though I still miss some of the things that Django provides for free (like the admin interface and user authentication).
I also use ClojureScript + Reagent, though not yet on the user-facing parts of the app.
pealim.com is my most visited site (according to the chrome home screen). I could not have learned עברית so quickly the last couple of years without it. תודה רבה!!!
On https://www.stackpair.com I'm using Go, Rails, Redis, Memcached, Minio, Sidekiq, Postgres, and Kubernetes on GKE.
The iOS app is Cordova: https://www.stackpair.com/apps/ios
For storage and backups I use Hubic and Rclone. Hubic is the best deal I've been able to find for LTS: 10TB for €5/m.
We [1] use a Laravel back-end for the main system, hosted on autoscaling EC2 behind a load balancer. Our front-end web application is built on Angular, running on S3 behind CloudFront. Since we process a lot of data, we use background jobs (with SQS as a broker) to perform our analyses. The actual data processing and wrangling is done in Python.
We have released some parts of our systems as open source projects [2], [3], [4].
[1]: https://odysseyattribution.co/ [2]: https://github.com/code-orange/telemachy [3]: https://github.com/code-orange/jot [3]: https://github.com/code-orange/statuspage
Great to see Laravel in this discussion! Beautiful framework.
A couple of questions:
1. Why did you go with Python for data processing instead of PHP?
2. Why not use Redis for queue/background jobs processing?
I agree! Lumen is my go-to framework for small web-based things right now, picking things from Laravel is so powerful.
1) At the time, Python (and with it pandas/numpy) seemed to be a good fit for the data we were working with (and the analysis was developed as a separate project from the main system that calls it). If we were to do it over right now (and we well might in the coming months) we would probably move this into PHP as well, which makes writing workers much easier.
2) Cost-wise, SQS makes a lot of sense - the system is highly distributed and cut up into parts (the description in my first comment is a bit simplified) so adding redis to the mix means adding a whole new server. For SQS, we're just paying per-message (and we don't have a _lot_ of messages, so it's cheap). Furthermore, I've built an algorithm to scale up the background workers based on the queue size of SQS. This runs in Lambda, which makes it super easy to access SQS properties versus connecting to a remote redis server. Basically, the algorithm rents new EC2 instances whenever the load is high and terminates them whenever the load is low.
We sell diagramming libraries, most notably (by sales volume) a JavaScript diagramming library: https://gojs.net
Our stack is: we don't care. One of us spun up a couple AWS resources and a windows machine with IIS because that's what he knew how to configure the quickest. It seems like it would be a waste of time to spend any more time thinking about it until we have a real need.
We have some orders database stuff we wrote ourselves ages ago with SQL Server that hasn't needed significant changes in 10+ years.
In other words, to us, the stack is whatever makes itself disappear the soonest so we can work on the actual product. Nothing fancy, nothing new, nothing changed for the sake of it.
If our product touched the stack more, we'd spend more time on it, but only insomuch as it was the product (if the product is a speedy website, etc).
Our workflow/cycle is all JavaScript based for the JS product. We push release with a gulp script I wrote.
As an indie founder, I prefer to use Node/Express and React/Redux, hosted on Digital Ocean. Really fast and convenient to build SaaSes and single page apps like:
https://nulis.io
https://helix.startuplab.io
If I don't need a lot of fancy interactive functionality, and am building more of a usual web 2.0 website, I sometimes go with Django/PostgreSQL:
https://fictionhub.io
http://webacademy.io
http://lumiverse.io
For static blogs and content websites, I go with pelican generated sites simply served with nginx:
https://startuplab.io/blog
helix reminds me of https://github.com/ioddly/meditations/
I'm curious if you prefer Django over js alternatives for any particular reason?
windows 200, ms access for the backend, ASP (VB) for the frontend.
we also do java applets
you probably meant Windows 2000 ;)
Windows Trajan emperor edition has a really good firewall up there (sorry for bad joke, had to make it).
Windows 200AD :)
:P I still write orchestral music with Cubase on a 1999 IBM PC running Windows ME. Writing this comment on my new (2005) computer with OmniWeb browser, os x 10.4. Hmm maybe I should be in healthcare.
Healthcare sector?
Healthcare Dev here. Its getting better! We finally ended support for IE8 last year!
Do you still support ie9&10 or have you moved on to 11?
We're not exactly a startup, but a small growing data science, analyst, and engineering team in a bigger company. You name it... but a typical data and web stack.
OS/Distros: FreeBSD and Linux (CoreOS and CentOS)
Languages: Python (Data Science) & Javascript (Front End)
Frameworks: Flask, Django, Angular, React, Bokeh, Tensorflow, Scikit-learn
Container Services: Docker, Mesos/Marathon/DCOS (currently testing Kubernetes in GKE - Google Cloud)
Databases: Redshift, Postgres, Cassandra/Scylla
Deployment Tools: Jenkins, Github, Gitlab (different team)
All running in AWS deployed through CloudFormation and Salt.
There's even a Windows Server 2016 instance thrown in there for good measure running Tableau. That's the most reliable part of our stack. </rolls-eyes>
Node.js/GraphQL/Next.js/PostgreSQL/AWS Lambada (via up). Entirely serverless stack with the application state residing in the DB and a JWT to identify the user. No OS, containers, kubernetes, instances, etc to deal with other than a single RDS instance.
We use Elixir, Go, C++ for backend and JS, Java / Kotlin, C# for frontend. We also use Postgresql, Rabbitmq and Redis.
How are you managing deployment of these many technologies? What does your CI/CD workflow like?
We mostly use docker with docker swarm. Currently exploring moving to Rancher. Also we use Gitlab CI for CI/CD. Our workflow looks like this: a release is tagged, CI tests and builds a docker image which is pushed to our private registry and then we use ansible to deploy the new release on our servers. We mostly use onprem for our production and can't use any cloud with the regulations and limitations we have.
I run a development shop in Australia and work with a lot of startups to build their MVP. This puts us in a position to recommend our preferred stack:
- Django backend
- React frontend
- Native mobile iOS/Android OR Xamarin (depends on project)
- PostgreSQL
- AWS (Elastic Beanstalk) OR Heroku
- S3
I am an experienced Django developer, but just starting with React. Can you point towards any source which suggests good project setup and structure?
I have not personally been involved with a lot of the development for the past couple of years. I could ask a colleague. Send me an email - james@blitzm.com
Do you serve React frontend directly from Django or from a dedicated Node.js or other server?
How do you find clients? I want to do something similar. Thank you.
You have the right approach. Sales first - send me an email (see profile)
What's your opinion on .NET Core?
We're building/selling "enterprise" software.
Multi-tenanted single codebase supporting both SaaS and self-host (Windows, Linux, macOS).
Stack:
- EmberJS front-end
- Go backend (static binaries that embed EmberJS GUI)
- MySQL database
- AWS EC2 pulling Docker images from Docker Hub
Python, Django, Go, Lambda, ECS, EC2, TS/JS, React
Not sure we qualify as a startup anymore but our stack is Kotlin + Gradle + Kubernetes on GKE.
Definitely the best stack I have worked with thus far.
what framework?
https://DNDEmail.com is do not disturb for your Gmail.
We use Python on Google App Engine. Google's NDB datasource.
The Chrome Extension is written in JavaScript.
Wordpress on wpengine.com for the front-end brochure website.
I've written about how to simplify your MVP stack[https://dndemail.com/2018/01/30/how-to-simplify-your-app-pla...] to speed up launching.
Webapp2 or something else? :) It's been so long I've seen someone use python on GAE, it's ridiculous. It was my first ever "real world" programming project back in 2011.
Yes, webapp2 with Jinja for the front end. For my endpoints I am just pushing json through webapp2. Simple to use and administer.
We use PHP. PureScript Haskell Postgres :) all on kubernetes atop AWS.
Elixir (Phoenix) in AWS Fargate.
Plain Ruby + Sinatra+ Puma + MySQL (ConnectionPool) + Sidekiq on Redis for the back-end. Sinatra/ERB for low-traffic sites, and ReactJS on S3 for more traffic on the front-end. I always like to err on the side of common denominator, rather than adding as many 'currently hip' tools as possible. Every time I try new things, it eventually brings me back to this set of tools.
At Shelf [1] we use:
Front-end: React, Redux, Vue.js, Meteor.js. Served from S3 via CDN (AWS Cloudfront)
Back-end: Node.js in AWS Lambda with AWS API Gateway, also Node.js in Docker hosted on AWS ECS, spot instances
Storage: MongoDB (on mLab), Elasticsearch (on Elastic Cloud), S3
Other: GitHub, Circle CI, Terraform, Jest
[1] https://shelf.io/
For anyone here interested, there's a website that has a nice UX for this: https://stackshare.io/
What I like about it is you can add open source projects to your stack, not just SAAS services. And also, you can split your server-side stack from your personal tools.
Meteor + React + MongoDB got eddtor.com really quick out of the door. But after 5+ years of maintaining my shipped products (I'm a freelancer, ME-JUST-ME kind of dev), my absolute happiness in customer service & maintanance was the most boring stack of all: PHP + HTML + JS + MySQL/MongoDB. Vanilla FTW.
MVC framework?
My present client has ASP.Net/SQL Server/Azure.
Not the greatest fan of Azure, mainly because of the admin portal, but apart from that it's been good.
Constantly get told by their clients that we do everything much faster than other SASS providers they work with, like weeks where others have turn arounds of months.
Backend: Java (phasing out), Go (phasing in), Postgres, Redis, all on Ubuntu EC2's.
Frontend: JS (TypeScript/ES6), React, ReactNative, SASS, all Webpack'ed (except RN).
I think it's a fairly light stack but am happy with it. I would use this as the starting point for pretty much every project.
I love Go, but always feel it is not very productive for web app backends. What about you ? Do you use an ORM w/ Go?
I don't use an ORM currently, just plain 'ol SQL queries. And in actuality I prefer it SOO much more. Like originally I was using Hibernate with the Java JPA, but I found it just got in the way a lot and the dependencies where finicky. Where as in Go and raw SQL I know EXACTLY what it's asking for and can pre-compose my queries externally. Any changes to the tables I have to make, as in renaming or adding columns, is just a quick change to the SQL query itself. And if needed, 1 line added to the Struct definition.
Also I'm more of a custom approach person which makes me very productive with Go. It's allows me to have laser focus on my needs instead of hooking up and reading docs and every little integration feature the framework has. And in result, I don't have dependency on a monolithic framework which could very well break everything in it's next release.
And finally, Go will build to binary for any-platform. So I can pre-build for the ARM processors, or Linux, or whatever else on Windows and just ship the binaries for server updates instead of managing make scripts and dependency resolution and blah blah blah. And if I wanted to I could sell the API "program" and sleep a little better about the IP contained in it (yes I know de-compilers exist). I could do this with C++ as well, but that's a whole 'nother ball game when it comes to tracking down memory leaks and segfaults.
Go optimizes for readability and lack of surprise at the expense of conciseness, which is why you feel it may not be productive. I think that the better maintainability vs. something like Rails massively outweighs the upfront cost of having to type more code, but other people might judge differently.
Furthermore, Go emphasizes "doing it your own way". There are no big web frameworks in Go, you just pull in some small and rather orthogonal libraries and make up your own abstractions to tie them together as you build your application. The end result is something that's highly optimized for your personal needs, but it requires a certain way of thinking and working that's not for everyone (and not always desirable). Some people do better when given more freedom; those should prefer Go etc. Some people do better when working within a well-known set of rules; those should prefer Rails etc.
Regarding ORM, I use Gorp (https://github.com/go-gorp/gorp) for INSERT, UPDATE, DELETE and basic SELECTs (e.g `SELECT * FROM things WHERE id = $1`), but when doing complex reports, I write SQL by hand [1] because ORMs are usually too constrained. I always feel like I know more SQL than the people who designed the ORM.
[1] For example: https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f...
I usually do the same, or even just sqlx. But then wish I had gone full-ORM when I have to change SQL code in 50 places due to a column rename...
I'm struggling to think of instances where you would want to rename a column without changing the behavior of the column. The latter would mean that you have to review those 50 places anyway.
In my opinion, it's great for web app backends as well. The net/http library suffices.
Just that you might need a library for routing like https://github.com/julienschmidt/httprouter
Yes - that part of the server code is great in Go. I use go-chi.
Gorilla Mux isn't bad either and is pretty tried and tested.
Also Go is one of the few (if not only?) languages with HTTP/2 built in to the standard library. Not to mention the gRPC over TLS that comes stock as well.
We are doing live video streaming, mostly Java and React.
Our backend is running on Kubernetes in Google Cloud. Streaming servers are hosted in AWS, but we are preparing to move to dedicated servers.
We also use Consul for service discovery and statistics for streaming servers.
(serious) hobby project: beanstalk, vertx, java, dynamodb, elasticache. Frontend: Kotlin.
We use Laravel for the backend and VueJS on the front end. Forge/Envoyer for deployments.
Amazon S3 for storage, db/redis for queue processing.
Great setup, a lot of the headache is taken out and lets us focus on the development aspects of creating software.
Backend: Python, Go, Java
Mobile development: Android and React Native
Database: MySQL and PostgreSQL
Redis and also RabbitMQ.
Could you please share your experience with RN?
Have you created an app from scratch or added RN to existing native app?
I have never created an apps or worked with React Native before. But, I would share the experience from my colleague who develops Android apps in our startup.
We are a startup that helps people in the middle-low income using technology. The people who use our technology usually have Android mobile phone with minimum specifications (Jelly Beans, low memory and spaces). At first launch, we used Android Native to build our application. The application meets our costumer needs since we consider to build an apps that consumes low memory and spaces. Then our costumer are growing and the features are complex, we use React Native to existing native app. Our application now consumes memory and spaces two times than Native one. Beside that, sometimes when you use a library, Native is more stable than React Native.
Rust on Linux with Cassandra, the strong typing without a GC is a boon to stability and performance (my own sanity). Cassandra is fantastic, looking forward to using Scylla at some point.
Would you mind if I asked what type of application do you have that needs the kind of write performance? Also, are there any Rust drivers for Scylla?
This stack looks awesome in terms of pure perf.
Ads (matching, serving, recording analytics), Scylla uses the same protocol Cassandra does. I've been using the CDRS crate which is pretty nice. It has a few rough spots that I've started to smooth over and send PRs for when I get a chance.
As a data company specialized in real time statistics for combat sports, we've built an API with Node.js + Hapi and MySQL. The front-end was developed with Vue.js.
Rails monolith, jQuery for some user interaction (new features are starting to use Vue.js). Hosting on Linode. Capistrano for deployments.
Nothing special, but it gets the job done.
Which service do you use for hosting your repository?
Github
Erlang in the Backend on DigitalOcean. React/immutable/requirejs/bootstrap in the frontend.
The integrations with payments and similar are Java on AWS Lambda.
Node and React/Redux, both with TypeScript. Starting to wish I'd learned PureScript so I didn't have to make do with Ramda for scaling.
Server-Side:
- Python with Pyramid
- SQLAlchemy with Postgres + Cassandra
- Celery with Redis
- Swagger
Client-Side: Mostly React, React-Native
Java (SparkJava Web Framework), PostgreSQL, Redis, Angular 4, S3 for files. Have also used Spring, Jersey, SQS, MongoDB in previous projects.
Context:
https://fibery.io - Work management platform for SMB
Stack:
Clojure
PostgreSQL
Kafka
React
Javascript
Backend:
Frontend (mobile app):How has Traefik worked for you? Is it serving production traffic?
i'd like to see this question answered only by companies grossing over $100 million and less side-dev passion projects.
My company is well over that number. I probably only know about a quarter of the stacks... And even within those, there is a lot of variation. There are java heavy stacks, python heavy stacks, nodejs, Ruby. Lots of systems level stuff in C, C++, Java. I can't even speak to any front end frameworks (although I know there are at least a few). Almost every other application you could think of is in use somewhere... Nagiod, Sensu, Icinga, OpenNMS, memcached, redis, nginx, Apache, redshift, MySQL, postgresql, rabbitmq, zeromq, Ansible, Chef... This is likely barely scratching the surface.
Don't companies over $100 million use almost every major stack?
COBOL, C++ and Java?
Elixir, React, Postgres hosted through Heroku.
I use Go + MongoDB. Hosting via Docker/Kubernetes in GKE. Gitlab is used for VCS, CI/CD and issue tracker.
Python/Django, PostgreSQL, React, EC2.
Using postgre, redis, FeathersJS, Nuxtjs, and VueJS. The near real-time updates and sever side rendering is great.
Python, Django, Postgres, Cassandra, RabbitMQ, Redis, MySQL, Nginx, HAproxy, Elasticsearch, Spark, React.
Python, Flask, SQLAlchemy, sklearn, numpy, Amazon Elastic Beanstalk, Postgres (on RDS). PowerPoint ;-)
Node.js / Express, Nginx, RethinkDB, Docker, tiny bit of Go. Preact / hyperscript frontend.
Python Flask, SQLite, some front-end framework that is available at the time, Linux Digital Ocean
Backend - Golang
Frontend - React app
DB: MySQL
How do you do migrations with Golang? Which ORM do you use?
For ORM we use GORM: http://gorm.io
For migrations we use goose: https://github.com/pressly/goose
This may be useful: https://github.com/mattes/migrate
Seconded. I use it with the go-bindata backend and Postgres driver. Some notes:
- Migrations are written in plain SQL, so there may be portability issues if you need to support multiple DBs. (Or you need to write the same migration once per supported SQL dialect.)
- It does not `CREATE DATABASE` for you when applying the first migration. For my app that uses Postgres, I wrote some extra code to do that. Feel free to copy if you like: https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f...
Backend API servers: Golang, Python, Redis
Frontend Web Servers: PHP (Laraval), JS (React), MySQL
ReactJS front-end, Grails back-end API with a PostgreSQL DB deployed on AWS.
Ruby, Scala, Postgres on AWS
Ubuntu, node.js, MongoDB, Mongoose, express, RE:DOM, stylus, nib, pug, ...
Company - www.LetsEnvision.com Stack: Swift, Obj-C Python C++ MongoDB
SQLite, ASP.NET Core, jQuery, Bootstrap. Kinda boring but works
I use Stackoverflow :)
Me too!
PHP (Laravel), JS (Vue + Vue Router + Vuex), MySQL.
Keeps things simple.
Python, Flask, Tensorflow, Keras, Amazon MWS, Boto
for my food site I use nginx as a proxy, Go for the server and Postgresql as the database. I deploy to digitalocean
for what? if its for analytics? we use Panoply and Chart.io sources are all over the place
- java
- dojo
- IE11
- jenkins
- we are not a startup :)
Backend: Node.js, SQL Server, Redis.
Frontend: React, Redux, Bootstrap via create-react-app.
Rails, mongo, elasticsearch.
Microsoft Products all the way... only way to scale.