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.)
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.