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.
Yes, the dynamic parts of the Tarsnap website are written in C.
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
tldr cperciva is a long time BSD guy...
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.
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.
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 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
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?
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.
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.
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:
For static blogs and content websites, I go with pelican generated sites simply served with nginx:
I'm curious if you prefer Django over js alternatives for any particular reason?
we also do java applets
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>
- Django backend
- React frontend
- Native mobile iOS/Android OR Xamarin (depends on project)
- PostgreSQL
- AWS (Elastic Beanstalk) OR Heroku
- S3
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
Definitely the best stack I have worked with thus far.
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.
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
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.
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.
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.
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.
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...
Just that you might need a library for routing like https://github.com/julienschmidt/httprouter
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.
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.
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.
Mobile development: Android and React Native
Database: MySQL and PostgreSQL
Redis and also RabbitMQ.
Have you created an app from scratch or added RN to existing native app?
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.
This stack looks awesome in terms of pure perf.
Nothing special, but it gets the job done.
The integrations with payments and similar are Java on AWS Lambda.
- Python with Pyramid
- SQLAlchemy with Postgres + Cassandra
- Celery with Redis
- Swagger
Client-Side: Mostly React, React-Native
https://fibery.io - Work management platform for SMB
Stack:
Clojure
PostgreSQL
Kafka
React
Javascript
- Go, NodeJS
- Redis, MongoDB, Tile38, Neo4j
- GKE
- Traefik
Frontend (mobile app): - React-NativeFrontend - React app
DB: MySQL
For migrations we use goose: https://github.com/pressly/goose
- 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...
Frontend Web Servers: PHP (Laraval), JS (React), MySQL
Keeps things simple.
- dojo
- IE11
- jenkins
- we are not a startup :)
Frontend: React, Redux, Bootstrap via create-react-app.