Live data from Hacker News

Ask HN: Go-to web stack today?

news.ycombinator.com

441–450 of 453 posts

Re: Ask HN: Go-to web stack today?

#441
My current preferences are

Large or complex apps (such as those at work or things I intend to have a long lifetime):

- Backend: Rails

- Frontend: Ember

The combination of these two is really powerful. I can focus on my complex problem domain and not have to make too many choices about project structure, testing setup, and other decisions that lead to bike-shedding.

Smaller applications (such as side projects):

- Backend: Rails, Phoenix, or Amber

- Frontend: Ember, (P)react

Rails & Ember are still very productive for small apps, but I'm finding Amber (written in Crystal, similar ethos to Rails) to be a faster, smaller alternative when a side-project is resource limited (plus, it's an interesting new community). Preact and React are quite good for building small things quickly or dropping into existing projects, so I've enjoyed them in that context. Ember and Rails are phenomenal over a long period of time, because they tend to have a relatively smooth upgrade path (in many cases with Ember, there are automated tools.)

I'm a strong proponent of Postgres. It gets better with every version and is great for both development and production use, especially if you want to do zero-downtime deploys (Postgres has some cool tools for avoiding locking of whole tables during updates, e.g. concurrent indexing, etc.)

Re: Ask HN: Go-to web stack today?

#442
I've been in full-stack development for about 10 years (most freelancing, 3 years full-time). I started with HTML/CSS, PHP, Ruby which I spent a couple years with before getting a full-time Ruby job. Since quitting my job 12 months ago to work on my own projects (while part-time freelancing), I decided to venture into a bunch of technology I'd not used.

I started to build a service in Elixir but found it lacked support for some crucial aspects (http/s tracing in this case). I've found it to be a very enjoyable language to work with (not just the Ruby bias talking), and a great cushion into functional programming.

Over there I've seen mention of Drab and Phoenix LiveView which piggyback on excellent websocket multiplexing to create an event channel between Elixir and JavaScript. This essentially means you can interact with the frontend of the application from the backend framework. There is a lot of discussion around performance/security implications, of course, but it is a great experience if you're backend driven.

Where Elixir couldn't meet my demands, Go did. It has `http/trace` in the standard library. It has static typing, it's fast, simple. Go has worked perfectly here as an "agent" of my main service. It is used purely to make requests and spit out results. I've found it much easier to deploy than Elixir (which usually involves distillery). Static typing in Elixir is often done through Dialyzer (annotated type-checking). In short, I'm saying I need both and that they complement each other.

I use a message broker to speak between the main service and the agents. Because I was using Elixir for the core service, I went with RabbitMQ. I've found that working very well on very modest hardware, and it is has been a big help having a well-known messaging standard to work with with available clients in different languages. To note - I only use this internally. Not sure if I'd expose this publicly in any way.

The database is always Postgres :P I use that with wal-e for backing up to s3. Still unsure on clustering. This is on a VPS because RDS and any other managed Postgres service was charging way too much for the hardware. With clients I would use RDS from the beginning.. and I would use Postgres as a document store before reaching for Mongo.

For managing servers, I either use the cloud provided cli (gcloud) or ansible on my own. I try to make sure I only ever use ansible to provision and modify them and everything is version controlled. This way I have a record of any changes I've made. I used ansible to setup wal-e backups on my Postgres instance. I'll also use it to setup clustering.

Other great tools on that may be Chef, Puppet, Terraform. Leaning more towards Terraform as it is agentless and declarative.

For application deployment I'm very much containerised. I've found Docker to have greatly simplified my deployment process once Docker itself is installed. As for clustering, Swarm is simple to setup. I was lured by Nomad, but I've decided to fully invest into Kubernetes instead.

I spent a good 4 months trying to setup a Kubernetes federation (cross DC) on a budget. Not easy. It was very painful. Best on my own was through Rancher after trying kubespray. Best in the cloud was through GKE. However, not happy with Google's pricing considering what else I can get. Digital Ocean released a Kubernetes offering and I can fire up a one node cluster (with free master plane) for $10/m which has 2gb ram on an ssd. For comparison, I think Google were charging me about $20+/m for 1.6gb ram with no ssd.

Within 10 minutes I can have a new cluster. I can apply my manifests to the cluster which have security policies, environment secrets, deployment strategies, health-checking. I can deploy my applications to it within minutes and easily integrate it with my CI/CD pipeline. I'm sure I could achieve similar with some cloud-native offerings (Google App Engine, etc), too, but I'd rather invest in something cloud-agnostic.

.. that's before even touching the frontend.

I decided to jump into TypeScript and VueJS. I'm still looking for that "unified" environment where all the layers and processes just seem to fit together. I've found the frontend ecosystem to be far too fragmented.

I don't see much point in creating any more complexity than VueJS already has. I use Haml for templating, SASS for extending CSS. Still unsure on a component/style framework. I think possibly Vuetify.

With all that said, my GO TO stack will eventually look like this:

* frontend: TypeScript/VueJS

* backend: Ruby, Elixir, Go

* database: Postgres

* message broker: RabbitMQ

* packaging: Docker

* container orchestration: Kubernetes

* CI/CD: Gitlab

* monitoring: Prometheus/Munin/Cloud tools

* logging: ?

* exception management: Sentry

* email: SendGrid

..man, could probably go on. It is never ending! I also think this is largely dependent on the size of the project. However, I still use those tools above on small projects because it forces me to become more familiar with the tools which I inevitably use on more important projects.

Re: Ask HN: Go-to web stack today?

#443
I recently created this full-stack project generator, based on previous ones I had: https://github.com/tiangolo/full-stack-fastapi-couchbase

FastAPI as the Python backend. Couchbase as the database. Vue.js with TypeScript, Vuex, etc. as the frontend. Celery for asynchronous jobs. All managed with Docker (including frontend compilation from source). All integrated with Traefik, so, automatic HTTPS.

Up to a month ago, I used my previous project generators based on Flask and several plugins, but now I'm doing all the backends with FastAPI as it's about 3 times faster to develop, and about 5 times or so faster (better performance).

Re: Ask HN: Go-to web stack today?

#444
Frontend

- Angular

- vanilla JS

Backend

- Springboot

- nodejs

DB

- MySQL

- MongoDB

HTTP server (if needed)

- Apache

OS

- centos

If the project is complex, Angular + Springboot are the best enterprise ready frameworks I've worked with.

If it's a simple project. NodeJS with Express for simple API requests. And on the frontend you rarely need a JS framework if the project is simple, not even a CSS framework.

As for the databases, MySQL, in my opinion, is the easiest RDB and MongoDB is a good all purpose DB.

Re: Ask HN: Go-to web stack today?

#445

- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…

Can you please elaborate on this part "just use cookies (Do not use jwt)". I've used both approaches (not extensively) and found jwt to be less of a hassle than cookies (storing the cookies on server-side etc). Are there any security vulnerabilities or other issues with using JWT?

Re: Ask HN: Go-to web stack today?

#446
I'm surprised that no one has mentioned Spring Boot or JHipster (Or maybe I missed it).

Please do look into JHipster.tech It builds production grade web apps in a matter of minutes! The backend is Spring framework and you can choose your frontend to be React/Angular/VueJs (I recommend Vue). You can pick a DB, testing tools, monitoring tools etc.

The generated app is ready to go into production and all major cloud providers are supported out of the box.

All you need is a well-defined data model.

Re: Ask HN: Go-to web stack today?

#447
post #92

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top? When I need a more dynamic page, I create a react app specifically for this one page. Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).

At my work we need APIs for integrations. The easiest path for us is to write the API and write an app to consume it. Although I suppose you could do the extra work to bundle a UI with the API and share the business logic. Also dog fooding helps us get the API right the first time. Im not 100% into the SPA world, in fact one of our clients is an MVC app which uses a mix of HttpClient to call our API and good old fashioned jQuery AJAX calls.

I just wanted to voice this and say if you live in a world where people do not need to integrate with your API then a regular MVC style app and little to no JS is fine. Also, JS helps when you need to do things like CRUD many-to-many relationships on your UI without a bunch of postbacks.

Re: Ask HN: Go-to web stack today?

#448
post #146

Earlier quoted context omitted.

Seconded on Django. It's excellent, especially if you get it out of the box with cookiecutter-django and DRF ( rest framework ) Plus, with things like Zappa it's easy to go entirely serverless Django + NewRelic for APM is plain magic EDIT: Oh, and Celery if your use case needs it. Brillant

So programmers are running servers on serverless platforms? Is this common?

Yes, it's super cheap and simple. Check out serverless.com to get started. Run your vue/react/angular app on a S3 bucket, and then only handle the API calls on lambda functions. Pay only for what you use, and it's infinitely scalable.

Re: Ask HN: Go-to web stack today?

#449
post #311

Backend: Clojure Datomic Luminus Frontend: ClojureScript Regent Datascript Datsync Some advantages: Immutability down to the database Database reads scale horizontally Impossible SQL injection from reading API Cache TTLs can be set to infinity Can ask for data at any point in time or do speculative writes Same programming language front and back Running queries within loops are performant due to data locality Query r…

Ultimate stack

Re: Ask HN: Go-to web stack today?

#450

Earlier quoted context omitted.

Although I think it's not a big issue, I'd look into Vue instead of React. Imo it's simpler and give you a more complete solution out of the box (routing, reactive data layer). Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Node might be a great choice due to you being able to use the same la…

i tried searching for the "Lucy ecosystem" in relation to C# and .Net but was not able to find any references to it. I'm guessing is an acronym for a stack, could you further clarify?

Meant nothing by it actually, it was simply a mistake/auto correct playing tricks with me
Post reply on HN