[temuze]

Reading the docs, I'm a fan of your authentication / session management. When anyone pushes JWTs on me, I get sad. Session revoking is a necessary part of any authentication system and making a Redis call doesn't take that long.

However, the downside of custom session managers is that other services might not be able to read/write the created session. For example, I'm currently to get off of Express and onto Fastify. Unfortunately, @fastify/session isn't perfectly compatible with express-session (although I'm working on it). I would have a similar issue if I introduced Next.js + Blitz... Sometimes, I wish there was a shared protocol for sessions between languages/libraries!

[temuze]

As an aside, this is the first time I've heard about Flightcontrol. Super impressed! The biggest con of something like Vercel is that you can't be on your own AWS VPC. An RDS instance with a public IP address (which Vercel's docs endorse) is a dealbreaker for me.

But... wouldn't a Terraform module accomplish something similar? Our own stack is something like Codepipeline + Fargate + ALB + Cloudwatch + Cloudfront and we basically just forked https://github.com/cloudposse/terraform-aws-ecs-web-app

[zoomzoom]

As someone working on a roughly similar product (withcoherence.com), I would highlight a few key reasons to prefer to a TF module: - maintainability (better to not have to maintain, audit, improve TF and keep up to date with best practices) - multiple environments (how do you create pipeline, CF distros, etc up to date with all your active branches). Even more - enhancements like using spot instances automatically for test envs. Maybe you already did that improvement or plan to do it, but a good example of where a platform might get ahead of your own fork. - discoverability/SPOF on team - how do you train a new dev on how to use these tools? much easier to train them on a nice UI. what if the person who forked that TF repo leaves the company? - integration to other environment types - Coherence is unique in this respect but how does your cloud footprint map to CI/CD testing envs, development envs, etc? Along with other open questions like how do you provide SSH access to the team across environments when needed? More stuff to fork and maintain... With something like Coherence, all of these questions are answered for you in one sane way (we configure a Cloud IDE and Cloud Shell automatically for all your environments) - Cross-cloud and cross-region support. Migrating your app to another provider or service is easier if supported by the automation tools. Coherence supports GCP and AWS for example.

All in all, buy vs. build is a tough question but generally SaaS wins once it is a viable option for real-world teams. In developer experience, we are still in the early innings on convincing folks it's worth it not to reinvent the wheel in-house.

Would love anyone interested to check out our free trial and feel free to ping [e-mail] with feedback or questions!

[bluelightning2k]

I think the whole point is you don't have to daisy chain a bunch of stuff. It's batteries included.