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.
I've been developing in Rails for the last 5 years, and am about to build my own products, and am opting for this kind of setup.. though have decided to hop over to Elixir on Phoenix, and will swap out Redux for Mobx. The application is mostly a dashboard (SaaS). Could easily be an MPA, but I want to move into more responsive UX, and wouldn't mind leveraging the portability for when I develop mobile or desktop apps.
It seems majority of these responses against SPAs are, as you said, all based on bad design, not because the architecture itself is fundamentally flawed -- though it is obviously going against the grain by breaking a lot of this functionality in the first place.
Having said that, the fact that browsers are providing native features to support SPAs, while bridging mobile-native features, is a massive sign of things to come. They're not going away, and support will only get better, and they will only become easier to develop.
Anyway, I'd be interested to hear about your custom router! Any particular reason you rolled your own? I was planning to just use react-router, but if there are headaches down the road in terms of managing a hybrid SPA with SSR, I'd appreciate the heads-up.
I'd say speed and syntax are the main reasons. I've used both Haml and Slim over 5 or so projects and the jump doesn't feel all that significant. If you know Haml, you can pickup Slim within a couple of days at most.
I see no reason sticking with Haml at this point. They are easily interchanged and have tools available to convert one from the other. Do your own testing, of course, but Slim feels even more productive to code in than Haml. It just feels like the way forward.
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.