[HN Gopher] Ask HN: What would be your stack if you are building...
___________________________________________________________________
Ask HN: What would be your stack if you are building an MVP today?
Specifically the backend. I'd love to hear your reasons. Do you
keep one eye on what the stack would be post MVP? 1. Old schoolish
(VPS - Maybe DO, Django/Flask/Rails/Remix/Next with postgres) 2.
Supabase etc with JS/TS on either side of the network 3.
Lambda/Cloud functions with Firebase/Dyanamo DB/Cosmos DB etc
4..n. What else and why?
Author : nvln
Score : 322 points
Date : 2023-01-26 10:37 UTC (12 hours ago)
| greenie_beans wrote:
| django + htmx + tailwind css + postgres + docker + render
| barakplasma wrote:
| Directus connected to a Postgres database
|
| Comes with a built-in low-config UI/API for CRUD on the database,
| and easily extendable with Vue.js and Express endpoints.
|
| Additionally, should the need arise for something more custom
| later on, all your data is in Postgres rather than a backend as a
| service
|
| https://directus.io/
| lta wrote:
| I've used it on a project a year ago and I've found it very
| effective for prototyping. But I eventually had to move out of
| it, and I don't see good you can make it work in the long run,
| as access management and data migrations are a PITA.
| jspaetzel wrote:
| A project I started about a year ago is PHP/Symfony/MySQL/React.
| It'll run on any modern lamp server so I've put it on a shared
| host I already had running for another customer.
|
| I'm going to deploy it on aws fargate sometime in the next 6
| months or so, that should get me to scale.
|
| The database I'm going to migrate to a single tiny ec2 instance
| until I need more resources, then it'll probably go to RDS or
| PlanetScale.
| amohn9 wrote:
| Whatever you know best and can set up quickly and easily. It's
| very easy as an engineer to focus too much on the tech and not
| enough on the product. Don't agonize over postgres or Dyanamo DB,
| Django or Spring, just use what you know to get it set up and
| focus on product, market, customers, sales, etc. Those will be
| the hard part.
| tdy721 wrote:
| Fresh, with Strapi to help bootstrap a backend, but eventually
| migrating all to Deno when the budgets permit.
|
| https://github.com/Hyprtxt/fresh-strapi.deno.dev
|
| This site uses the framework, but not Strapi:
| https://videopoker.academy
| zoomzoom wrote:
| Choose something from bucket 1 and pair it with an own-cloud PaaS
| such as what we're building at withcoherence.com! There's nothing
| that will help you move faster than using well-understood tools
| with huge ecosystems, and freeing yourself from glue code and
| internal tooling.
| Kalanos wrote:
| Python: SQLite ORM with PeeWee + realtime UI with DashPlotly
| https://betterprogramming.pub/dash-is-deeper-than-dashboards...
| jFriedensreich wrote:
| - for edge functions cloudflare workers are currently the best
| mix of being modern and professional/feature rich
|
| - nothing beats the simplicity and power of svelte for UI
|
| - netflix falcor for state and request management, because it has
| the 90% of features of graphQL i need but is much simpler to
| reason about and i can auto generate nearly all my requests from
| svelte without writing queries (because falcors model matches 1:1
| to POJOs and has optional schemas so prototype at lighting speed
| and then add schemas later as needed for reliability)
|
| - pouchdb/couchdb because nothing beats this combination for sync
| and offline and low latency features
| caseyf wrote:
| Rails
| davide_v wrote:
| It depends on the MVP, but I'd (still?) use the MEAN stack with
| the latest Angular and Node. Expecially because I made a
| boilerplate [1] that allows me to start any project faster.
|
| [1] https://github.com/DavideViolante/Angular-Full-Stack
| danwee wrote:
| - VPS like DO
|
| - Server-side rendered app with Golang
|
| - If interactivity is required: maybe Vue.js or jQuery
|
| That's it.
| stets wrote:
| Rails!
| nicolashahn wrote:
| Kotlin. Seems like the true successor to Java rather than Go.
| Comparable speed but much more enjoyable than Go due better type
| system, quality of life features, and the massive ecosystem of
| Java.
| [deleted]
| seagull-action wrote:
| I've had an unparalleled experience in getting an MVP live with
| shuttle[0] - nothing is as fast for deploying a web app with a
| database to the cloud. For the database I've used shuttle's
| dedicated SQL DB instance[1] and for the front-end I've used
| shuttle's static file server[2].
|
| If you are not scared of diving a bit into Rust, I'd a 100%
| recommend it.
|
| [0] https://github.com/shuttle-hq/shuttle [1]
| https://docs.shuttle.rs/resources/shuttle-shared-db [2]
| https://docs.shuttle.rs/resources/shuttle-static-folder
| machekb wrote:
| For something in the same vein but for Go, there is Encore:
| https://encore.dev / https://github.com/encoredev/encore
| tonymet wrote:
| Old school mono repo . VPS. golang + sqlite .
| itslennysfault wrote:
| I really like NestJS for backend. It has great tooling and
| generators. It's super fast to create a REST or GraphQL API.
| Adding WebSockets is a breeze if you need them. It uses TypeORM
| which is rock solid. Also, it includes unit and e2e tests and
| linting out of the box. Also, if you're doing your frontend in
| TypeScript it's trivial to share interfaces for "type safety"
| across the wire.
|
| https://nestjs.com/
| ilrwbwrkhv wrote:
| I tried everything from supabase to rails. These days if I need a
| quick mvp it's built with Imba on the front-end and Pocketbase on
| the backend. The installation and deployment story of Pocketbase
| is the easiest.
| iainctduncan wrote:
| I am building one now as a single founder, with plans to never
| grow beyond a few people, and I'm using Clojure + Postgres
| (having done Python for almost 20 years!). I do technical due
| diligence for private equity companies for a living, and I
| evaluated two Clojure companies. It was amazing how much they
| could _avoid_ in terms of problems as a small team by leveraging
| the JVMs concurrency and threading capabilities. No worrying
| about microservices, managing crazy k8 systems, or complex CQRS
| problems, no outgrowing pokey ORMs (a problem I have talked to
| way too many mid stage companies about who started on Rails or
| Django - huge elephant in the room there). I intend to use a mix
| of HTMX, some Reframe (a clojurescript reactive framework over
| react) and webassembly on the front end.
|
| Clojure's not the easiest thing to get into, the stability and
| documentation and libraries are great.
| gavinh wrote:
| Django and HTMX
| mekoka wrote:
| My priority is to get things done. Ubuntu (DigitalOcean VPS),
| Django, Postgres, HTMX. I'm going full old school boring tech. No
| excitement. No drama. I might even go typeless if the code is of
| reasonably manageable size.
| ye-olde-sysrq wrote:
| Same but with Rails and traditional server rendering if it's
| feasible. I know React is becoming boring tech but imo it's
| just so much faster to bang out most of the boring pages
| server-side and then if you really need it, break out "cooler"
| client functionality into its own React sub-app.
| mekoka wrote:
| React has new friends all the time and they're not boring
| enough.
| fzaninotto wrote:
| If you're building a B2B app:
|
| - Supabase on the backend (REST APIs are a solved problem, no
| need to spend a single hour on it)
|
| - Auth0 for authentication (too risky to manage authentication
| manually)
|
| - react + react-admin SPA on the frontend (does 80% of the job
| for B2B apps)
|
| - lambda functions (for business logic that can't be exposed on
| the frontend)
|
| API-centric SPAs are such a time saver... when you don't have to
| build the API, and Supabase covers it.
|
| For a B2C app, you must render server-side. I'd go with:
|
| - Postgres - Next.js or Remix - Prisma
| jasondigitized wrote:
| Why must you render a B2C app server side?
| fzaninotto wrote:
| Because of SEO: SPAs aren't good at using robot time
| efficiently
| pstorm wrote:
| Curious why you suggest Auth0 and Supabase. What is wrong with
| Supabase auth?
| stcroixx wrote:
| Java and Postgres. For large numbers of devs, this is a very
| intuitive stack they have lots of experience in and can get work
| done super quick. Also won't have to rewrite later because good
| performance. I'd stay away from depending on any vendors for
| anything except a VM to bring your servlet container up on.
| redbar0n wrote:
| I'd likely go for a mobile first approach and start with:
|
| create-universal-app : https://github.com/chen-rn/CUA
|
| Which would give me: - Tamagui - React Native Web Lite - Expo -
| Next - Solito - Prisma - Clerk - tRPC
|
| But I'd likely throw out Clerk for a cheaper option:
|
| - Supertokens, since it's also easy (lots of enthusiastic reports
| about it), has a managed solution (which is cheaper than the
| alternatives), is secure and scalable (rotating refresh tokens
| with JWTs), open source, offers passwordless / magic links, and
| the architecture of Supertokens would allow me to simply and
| quickly eject to self-hosting it if/when I'd eventually need to
| (if the app ever reaches mass-market scale).
|
| And I might throw out tRPC for the equivalent GraphQL and
| TypeScript inference experience (esp. if business strategy
| dictates I need a 3rd party API):
|
| - GQty.dev on the client, for inferred queries/mutations. For
| rapid dev speed. Simple code example: https://gqty.dev/docs/intro
| Then move to URQL or Relay at scale, or just skip GQty and go
| with URQL from the start (if scalability trumps dev speed).
|
| - Pothos http://pothos-graphql.dev on the server, for auto
| building the schema from your TS code (aka. code-first). Better
| than Nexus (e.g. Max Stoiber moved from Nexus to Pothos on his
| Bedrock starter template because Pothos is best in class:
| https://bedrock.mxstbr.com/tools/pothos/ ).
|
| And I might throw out NextJS (Webpack) for the equivalent
| experience in Vite:
|
| - vite-plugin-ssr, since both architectural control (libraries >
| frameworks) and Vite rocks. I'd likely then have to make solito-
| vite https://github.com/nandorojo/solito/discussions/157 to have
| a unified navigation between React Native and Web, but Solito is
| allegely tiny, so recreating it should be doable.
|
| (If doing all of these replacements, maybe starting from scratch
| would be easier than modifying create-universal-app ... That
| said, I think if someone made a starter repo with the above
| choices it would be a real killer!)
|
| Then I'd also likely use:
|
| - Vercel (and try their Edge Functions, for a serverless sweet v8
| isolates experience without slow cold starts), or maybe
| Cloudflare Workers (cheaper, slightly more hassle?) for hosting.
|
| - Planetscale or Supabase for the DB. (Not brave enough to try
| EdgeDB or SurrealDB just yet, though EdgeDB is close..) Unless I
| had a specific use case where a more specialized/optimized DB
| would make sense.
|
| This stack should stick even post-MVP, as it's not only optimized
| for a solo developer but for scalability.
| zyklonix wrote:
| <half-joking> https://github.com/TheAppleTucker/backend-GPT
| </half-joking>
| quickthrower2 wrote:
| I used NextJS and Firebase and while I disliked some of it: I
| would use it again because if the benefits of speed in building.
|
| With this setup you can permanently host for next to nothing
| until you get users, do zero devops or ops, and have something
| that will scale up (wont be the fastest thing but it will be OK
| and will scale)
|
| You could switch out NextJS for a static site generator too, but
| NextJS is pretty convenient and is a superset of a static site
| generator with everything wired up nicely using React.
| nvln wrote:
| Thank you, 'the next to nothing' bit is very helpful. I'd like
| to have a decent runway and a decent protection for my wallet
| just in case the MVP takes off in terms of user growth but not
| in terms of revenue growth.
| senttoschool wrote:
| I would not switch out NextJS for a SSG. NextJS can do SSG. But
| most SSG frameworks can't do SSR nor CSR.
| yakshaving_jgt wrote:
| I'd use Yesod and SQLite, and run it on a Hetzner machine.
|
| KISS.
| sirjaz wrote:
| I'd go with blazor and asp.net core. Stupid fast and easy to
| build with c#. No javascript needed
| zxexz wrote:
| Probably React for the frontend, Postgres for the database,
| PostgREST to serve up a REST API, Nginx for routing. Any services
| or tasks not done in the DB directly written in one of Python 3,
| Kotlin, or Go. Pretty much any generic search task including
| freetext is easy in Postgres, but if I need more I'd throw in
| Elasticsearch.
|
| Building an MVP should be done with the tools you're most
| comfortable with!
| omarhaneef wrote:
| I think question should include the size of the dev team.
|
| Solo dev vs 50 devs might need different tools just to get out of
| each others way.
| mmcclure wrote:
| Old schoolish and Phoenix. I haven't seen any of the new (very
| cool!) projects in the JAMStack-y space really address things
| like migrations or even the data layer at all outside of "go use
| something else."
|
| Ecto is the best ORM-ok-fine-it's-not-an-ORM I've ever used and
| Phoenix is a lovely framework that borrowed a ton from the
| success of Rails. Deployment used to be a bit of an achilles heal
| (in that it was uncharacteristically difficult compared to
| everything else about using it), but that's gotten _so_ much
| better in recent years. Even more simple if you just use
| something like Fly.io, which has incredible first-class support
| for Elixir/Phoenix.
| tamasnet wrote:
| Spring Boot + Hilla (https://hilla.dev) + PostgreSQL, deployed on
| a Digital Ocean VM, possibly behind CloudFlare.
| leonidasv wrote:
| Google Cloud Run (with Dockerfiles) + CloudSQL (Postgres) + Cloud
| Tasks.
|
| On the back-end, NestJS with Typescript plus some query builder
| such as Knex (TypeORM is pretty buggy). Or maybe even try Prisma.
|
| For front-end it depends. I would try using just Vanilla JS with
| Tailwind if possible or fallback to React + Tailwind if there are
| too many screens, or they need a lot of updates based on state.
|
| Those are mostly technologies I'm comfortable with because I use
| them every day. However, if I have the option to waste time
| researching and/or learning, I would research the state of
| server-side Kotlin and learn Elixir/Phoenix before making a
| decision. NestJS can ge too verbose sometimes.
| jononomo wrote:
| I would use Supabase for the database and user auth system, I'd
| use Elixir/Phoenix for the business logic, and I'd use Phoenix
| LiveView for the front end, with Tailwind for the CSS.
| apocalyptic0n3 wrote:
| For an MVP, I'd choose what I'm most familiar with and can be
| fastest with. That would mean:
|
| 1. Laravel
|
| 2. An Ubuntu VPS in either Digital Ocean or Linode
|
| 3. A managed database in one of those services, likely Postgres
|
| That would get me to market the quickest. I have no issues with
| the application being in Laravel/PHP and after getting to market,
| I'd work on making the infrastructure scalable. I wouldn't expect
| overnight success, so a single VPS and managed database would let
| me keep costs low while I pick up a few customers and then work
| to handle the scalability in the background (likely AWS with a
| combination of EC2/ECS/Fargate, RDS, SQS, SES, CodeDeploy,
| ElastiCache, etc.)
| mooreds wrote:
| > For an MVP, I'd choose what I'm most familiar with and can be
| fastest with.
|
| That is absolutely the takeaway here. Use the technology you
| are familiar with and/or can be fastest with. MVPs are risky
| enough, don't add in "oh, gosh, I have to learn the tech
| (libraries, deployments, monitoring, database access, etc)" as
| well.
|
| The only case where I'd pick a new tech for an MVP is when
| there is an existing open source or free project that I could
| use that would obviously get the project shipped faster by
| providing extensive pre-built functionality.
|
| For example, I once used Sharetribe
| https://github.com/sharetribe/sharetribe even though I was only
| an intermediate ruby programmer because, after time spent
| evaluating it and other solutions, it had functionality that
| could get us shipped faster.
|
| From "git init" to our first beta customer was 1 month of time.
| Then to our first paying customer was 1 more month. One
| developer (me). To be fair, my co-founder had done a ton of
| market development before I started coding, so the initial
| market/feature discovery was done; that's a huge part of any
| MVP.
| bittermandel wrote:
| 1. FastAPI (Python) or Axum (Rust) for back-end, deployed on
| Fly.io.
|
| 2. Supabase for Postgres and Authentication.
|
| 3. Astro as a framework for front-end, deployed on Vercel,
| running in Hybrid mode.
|
| With all of these in-place, I can extend my existing components
| to accommodate any needs. It scales very well in the beginning as
| I move very fast, and anecdotally scales very well regardless of
| size.
|
| The only missing parts here is support for timed jobs, but that
| can probably be done with Fly.io machines in the future.
| comprev wrote:
| I'm building my first solo MVP using Falcon. The product will be
| REST API only with the exception of signup/payment pages,
| although a friend is helping with that in Laravel, as webdev is
| his thing.
|
| For hosting I'll use Hetzner.
| cunningfatalist wrote:
| Symfony. It's just so much fun to work with.
| pc86 wrote:
| For the database, anything that's managed - I'm partial to SQL
| server just based on my work history, but Postgres is nice too.
| Even the expensive ones are like $100/mo for the lowest
| production tiers, if you're bootstrapping with a W2 job that's
| reasonable for 6 months while you try to find some level of
| traction.
|
| For the backend, probably default to JS or maybe TS
| lambdas/function apps. Quick to write, quick to deploy, slap an
| API gateway over the top and you're ready to go.
|
| For the front end, for a true POC I have a lifetime/full Creative
| Tim membership. So I'd just grab a dashboard and landing page
| template and start plugging in calls to the API gateway.
| rawgabbit wrote:
| This sounds ideal to me. Are there any tutorials or resources
| that can help me use this stack? Thanks.
| morphle wrote:
| https://www.youtube.com/watch?v=QTJRwKOFddc
|
| Smalltalk, Squeak, Pharo, Seaside, PierCMS, Lively Kernel
|
| Used by several succesful startups.
| CuriouslyC wrote:
| I'd use Postgres for the data layer, I'd build the service layer
| around OpenFAAS (using faasd) and Node/Typescript functions, and
| for the client I'd probably go with React/Next (though Svelte is
| starting to look pretty attractive). For basic CRUD functions I
| would probably use Postgrest.
|
| I'd stand it up on a VPS initially, using ansible scripts to make
| switching deployment targets to AWS easy.
| blascsi wrote:
| I've been trying to put together a solo project, that might be
| worth launching a bit later. My stack in general is:
|
| Elixir for the backend. Reasons for it:
|
| - Elixir is designed for reliability, so since I want to keep the
| app alive as much as I can by myself, it seems like a great fit.
|
| - It also has excellent integrations with Postgres (my choice of
| DB) with Ecto.
|
| - I generally skipped Phoenix, as I'm just using Elixir to create
| my API.
|
| - Absinthe provides amazing support to create GraphQL API from
| scratch.
|
| Frontend will be React probably with Relay.
|
| - I've been using React at my job for years with GraphQL and I'm
| pretty fond of it.
|
| - I've been planning on investingating Mobx, as I've never used
| it but heard good things about performance there. I'm not sure if
| it's going to be worth using it with GraphQL
|
| - Relay has quite a lot of boilerplate, but I found it good
| enough for what I'm doing, and I liked the performance. Also it's
| fairly easy to integrate with Absinthe.
|
| - Generally since this project is not made to be a start up or a
| business first, I want to experiment on the front-end on how I
| could reach the best performance with these tools at hand.
|
| - I plan on using TS with the GraphQL queries mostly generated
| from the schema.
|
| For deployment I plan on using a VPS probably, though I'm way far
| from having to choose that.
| 0xblinq wrote:
| My issue with Phoenix (or Elixir..) is that there are like 3
| people in the world using it. The community and the third party
| packages available is minimal compared to other ecosystems.
|
| And in my opinion, it is already past its best days. I know of
| several companies in my area that a few years ago chose it for
| building their services and ended up, or are migrating to other
| stacks because of their problems hiring.
| karmajunkie wrote:
| > there are like 3 people in the world using it.
|
| This is flat out untrue.
| ch4s3 wrote:
| > - I generally skipped Phoenix, as I'm just using Elixir to
| create my API.
|
| Why specifically? Phoenix is mostly just some convenience on
| top of plug, but does a lot of things you'll have to reinvent.
| codeptualize wrote:
| I'm currently building an mvp using Supabase & Next.js (FE & api
| routes). I can definitely recommend.
|
| My main reason is speed; you can move very fast, and lots of the
| "boilerplate" stuff is handled out of the box.
|
| I do keep post MVP in mind, it should be pretty easy to move
| parts to different systems if necessary. The most radical exit
| would be moving the Postgres DB elsewhere, or even self hosting
| Supabase.
|
| It's good that it's possible, but I plan to use this stack as
| long as possible as it's great, and I have zero interest in
| managing and maintaining infrastructure.
|
| As with everything; it depends. On your product and on your
| skills/expertise.
| turbobooster wrote:
| WordPress + mysql
| codazoda wrote:
| I'm still building personal stuff in the style of "1. Old
| schoolish".
|
| I'll use a VPS or host it on the Raspberry Pi in my bedroom[1]. I
| use these primarily because I'm worried about price complexity at
| cloud providers.
|
| I use a mix of languages for personal stuff and I'm finding Go
| quite addictive at the moment. I rarely use a framework and base
| most of my MVP's on the simple Neat CSS framework[2] I created
| for that purpose. I like to keep stuff light.
|
| I've started to create some live coding style video's[3] of
| myself doing these projects with a goal of setting a schedule for
| myself and an ultimate goal of creating a micro business.
|
| 1. https://joeldare.com/private-analtyics-and-my-raspberry-
| pi-4...
|
| 2. https://neat.joeldare.com
|
| 3. https://www.youtube.com/codazoda
| golondon wrote:
| Whatever you are most productive with.
| adav wrote:
| Whichever "boring" technology you're most
| familiar/fastest/productive with. It rarely matters. Don't waste
| time learning a new language/platform when you should be testing
| the idea itself as quickly as possible.
| rouanza wrote:
| this https://create.t3.gg/
|
| typesafe next react trpc and prisma
| ianbutler wrote:
| Elixir, either Ash or Phoenix frameworks
|
| Postgres
|
| React - createreactapp
|
| Theres a few react frameworks I might sub out for now but
| otherwise this combo is a way to get things done right and
| quickly.
| princevegeta89 wrote:
| Maybe the standard Node and React on the front end? Tried too
| many niche languages and technologies and now I always come back
| to JS to stick to the same platform for everything
| m0llusk wrote:
| Basic REST inspired service made with node and expressjs
| implementing business logic based interfaces and all data stored
| in Postgres. Most objects get UUIDv4 identifiers. Logging is with
| pino. Everything gets kept simple as possible so that junior
| developers can easily handle operations, basic extensions, or
| debugging.
| digvalley wrote:
| - NextJS
|
| - Tailwind
|
| - Hasura / postgres
|
| - DigitalOcean - docker droplet
|
| - Caddy
|
| - Cloudflare
| collaborative wrote:
| I could explain what I'd choose, but that's irrelevant as it's
| based on my existing skills
|
| The one thing I can't recommend enough is the value of organizing
| persistence around a nosql distributed db and blobs of zipped
| files (also distributed)
|
| In my experience, db is expensive. But this setup is dirt cheap.
|
| Sqlite is good but it makes you worry about scaling (so it's
| great for an MVP)
| reducesuffering wrote:
| Next.js for both backend (server React and REST API) and
| frontend. Prisma ORM to Planetscale DB (mysql auto scaling).
| NextAuth. TailwindCSS. Typescript.
|
| Very simple, very easy to deploy and scale, and in-tune with all
| the best practices of fast frontend (auto caching, SSG, ISR,
| prefetching, client side nav, etc)
|
| Didn't like Django. Deployment more annoying, templates are weak
| and DSL-specific, React integration is poor and then DRF is a
| strange verbose monstrosity.
| notsrg wrote:
| T3 stack - Typescript, TRPC and Tailwind (uses NextJS, Prisma,
| etc). This is the closest in the JS/TS world to something like
| Django and end-to-end typesafety can enable you to go blazingly
| fast. Copilot became pretty good at autogenerating my
| queries/mutations for me too which was nice.
| paulclark wrote:
| Building with this stack right now, really enjoying it and more
| importantly able to move quickly as a solo builder.
| Supabase/Railway/Neon/Planetscale all good choices for hosted
| DB.
| biftek wrote:
| A lot of these suggestions sound needlessly complex but I'm
| probably just getting old.
|
| I'd say either CGI scripts, PHP, or Ruby and sqlite as a DB, all
| hosted on a single VPS. That'll get you plenty far and be easy to
| grow out of.
| demircancelebi wrote:
| T3 Stack (Next.js, Typescript, Tailwind, tRPC, Prisma) with
| Postgresql (Supabase is a good free choice), deployed on Vercel
| w/ Github Actions. These give you the ability to iterate rapidly
| and is the best choice in the market imho. https://create.t3.gg/
| gregjotau wrote:
| - Spring boot (Java 19)
|
| - HTMX + Thymeleaf (replacing need for any SPA framework)
|
| - Bootstrap
|
| - Vanilla JS when needed
|
| - Postgres
|
| - Deploy on Ubuntu server with a deploy.sh that just does cd =>
| git pull => gradlew build => systemctl restart X.service :)
|
| Why? I have been convinced that most web application can and
| should be created without JS frameworks :P
| itpragmatik wrote:
| - Backend: Java - Front end: React - Persistence: MySQL and S3 -
| Dockerize containers for backend and front end - AWS CodeCommit
| for code repo - AWS CodeBuild and CodeDeploy for CI/CD - AWS ECS
| Fargate
| itpragmatik wrote:
| Java aka Spring Boot 3.x
| gbraad wrote:
| Unclear description of requirements. Even as a green field
| project you base these on the environment it needs to operate in,
| the team that will work on it, and/or based on requirements of
| the actual functionality. And if for your own project, base it on
| something you know. Learning a new stack and developing an mvp
| does not go well. You would be struggling more to make it work
| than making progress.
| EMM_386 wrote:
| I'm going to buck the (numerous) trends here and keep it simple
| at the same time.
|
| C# REST APIs on Linux with PostgreSQL and the front-end framework
| of your choice. I generally stick with Angular.
| isanjay112 wrote:
| I use the exact stack. I even develop on Linux using Rider. :)
| cehrlich wrote:
| T3 stack (Next.js, tRPC, Prisma with MySQL, NextAuth, either
| Tailwind or a component library depending on the project),
| deployed to Vercel. Maybe swap Prisma for Kysely if cold starts
| become an issue.
|
| Disclaimer: I maintain an init tool for this stack so I'm
| somewhat biased
| marcus_holmes wrote:
| Go & Postgres on the backend, running on a baremetal server.
|
| Because this is actually capable of handling a decent workload
| for really cheap compared to cloud.
|
| There's a few tricky bits to do with logs and reporting, but the
| benefits outweigh the pain.
|
| Vue on the frontend.
|
| Last time I used BootstrapVue and it worked well. I'd want to re-
| evaluate that decision next time, have a look at some of the
| newcomers. I'm aware Bootstrap is now considered to be passe.
|
| I really like the Vue philosophy and it pairs with Go nicely.
| Last time I ended up using ESBuild to actually build the Vue
| bundles from inside the Go server, which was interesting but I'm
| not sure I'd do that again.
| caeril wrote:
| This is the correct answer. It's quite shocking how many Django
| and Laravel answers there are in this thread. Performance and
| type safety appear to be completely irrelevant to HN.
|
| You should take a look at Vite (https://vitejs.dev/) for a Vue
| development environment, if you haven't already.
| 0xblinq wrote:
| No, it's not, because we're talking about an mvp and not
| about building an ultra high performance micro service.
|
| And btw, there is no "correct answer" despite how much you
| like it.
|
| There are many "correct answers" and a lot more wrong ones.
| Like using assembly code for building a CLI app or Go for an
| MVP.
| lelanthran wrote:
| > This is the correct answer. It's quite shocking how many
| Django and Laravel answers there are in this thread.
| Performance and type safety appear to be completely
| irrelevant to HN.
|
| I was wondering about that actually.
|
| Writing code in Python, Rails, etc is _painful_. A stupidly
| high percentage of the "unit tests" aren't testing logic at
| all, they're simply ensuring that incorrect types are handled
| properly.
|
| And then I see comments like _" well, my MVP can run very
| cheaply, a $100/m DO droplet"_ and wonder what on earth they
| are talking about - I had a $5/m DO droplet handling around
| 50k-60k concurrent TCP (not HTTP) connections, all serving
| data without any of the connecting devices timing out.
|
| The devspeed differential between things like C#/Java/Go and
| Python/PHP/Ruby is large _only at the very beginning_ of your
| project. When you 're adding new features in every day, six
| months into the project, you're almost definitely going to be
| faster in some statically typed compiled language.
|
| Seriously, using Django is likely to shave a week or so off
| the time; if that week matters so much then your expected
| lifetime for the product is what? Two weeks? Three?
|
| I get it, in that if your MVP is timeboxed to (say) two weeks
| to alpha, then, yeah, those things that shave a week off make
| sense. But if your MVP is timeboxed to two weeks:
|
| a) Tt's unlikely to be of much value to the consumer, b) Your
| competitors will appear two weeks after you first launch
| _anyway_.
|
| I want to do a new product, and when judging each product
| idea I have, the largest issue is always finding the largest
| amount of value I can create/deliver in a particular
| timeframe (say, 3 months f/time).
|
| If the value the product is providing can be done in a week
| with Rails, then there's not much motivation for me to
| develop that product - everyone with a week of leave or a
| month of weekends is going to have a clone out before I can
| even learn marketing.
|
| If it's going to take 3 months regardless of the language, I
| have at least 3 months to build up a userbase, and do product
| refinement and fit.
| RangerScience wrote:
| > The devspeed differential between things like C#/Java/Go
| and Python/PHP/Ruby is large only at the very beginning of
| your project.
|
| That's a massive hard-no for me. I generally only get
| _faster_ the longer I get to work with a Ruby codebase, as
| I get to make it more and more into a DSL for the business
| situation. I never saw that happen with compiled languages;
| my speed tended to remain constant after the initial boot.
|
| I know what you're talking about tho - it's the sharp
| knives + large team problem. The language doesn't maintain
| a standard of code for you, you (and your team) have to do
| that yourselves, and if you don't, things can _very much_
| get bad. If you 're programming in a loosely typed language
| such that you're effectively having an explosion of types,
| you're suffering one of the more common downsides to typed
| languages _and_ you 're not using the common upsides to
| loose typing.
|
| That said - when _I 'm_ working, the main difference I've
| seen with Ruby (and, to a lesser extent Python and JS) vs
| compiled is the iteration loop, particularly due to having
| a REPL console. Static languages have definitely made some
| gains there (looking at you, Scala REPL). Being able to
| drop into both any debug point in the program, as well as a
| console loaded with your code, makes certain explorative
| processes substantially faster.
| marcus_holmes wrote:
| thanks for the tip, I'll check it out :)
| jamal-kumar wrote:
| I'm of a similar philosophy, but also because I'm not beholden
| to rushing a minimally viable product to the feet of some angel
| investors (Super allergic to that after a few experiences). I
| mean it's kind a a premature optimization if you just need to
| get a working example out there for people who like to see fast
| results, but if you've got the funding to start your own
| company just writing it properly for performance from the get
| go is the obvious thing to do.
|
| I also choose a stack like that because it's what I've been
| mostly working in for a long while now and it's really
| productive (For me).
| marcus_holmes wrote:
| yeah, I get the same - I'm probably not going to get
| something up as fast as I would if I used Rails (though it's
| probably close - I've built so many sites on this stack that
| I know all the pitfalls and have a lot of the boilerplate
| down to copypasta now).
|
| But this backbone can take a lot of experimenting with
| features easily, and is fast enough to forgive a lot of sins
| - I generally just don't have to worry/think about
| performance at all.
| ericfrazier wrote:
| Definitely no mvc or mvt bs. No frameworks. All from scratch,
| because I enjoy coding.
| 0x008 wrote:
| Svelte and Pocketbase
| Gordonjcp wrote:
| Django for the backend, Bootstrap for the frontend.
|
| I actually prefer Flask and SQLAlchemy, but I haven't found
| anything to beat Django for sheer "ten minute POC lets-do-the-
| show-right-here" pulling something out my arse.
| Thaxll wrote:
| There is only one good answer to that, you should use what you
| already know, if you build an MVP it's to deliver a product, it's
| not meant to spend 2-3x more time to learn new tech.
| chronofar wrote:
| This is the most common advice around these parts, but it seems
| woefully misguided to me.
|
| The "only good answer" if there is just the one is that you
| should use whatever fits the requirements. If those
| requirements involve you getting to market as fast as possible
| in a highly generic domain (ie building a standard website)
| where the tools you know work just as well as others and you're
| not worried about various other factors then sure, go with what
| you know and can churn out the fastest.
|
| But though many projects may fit this mold they are by no means
| universal requirements, and your requirements may very well
| dictate the best path is for you learn new tech (for instance
| if you usually do .NET stuff but are building a a ML service on
| a device or something). Sometimes there are better ways to
| accomplish things than what you already know and you'll indeed
| be better served by learning them. If you're just a hammer
| looking at everything as a nail because you can bang on it the
| fastest you'll stub your (and probably others') thumbs one way
| or the other.
|
| Not to mention learning new tech is often its own reward
| regardless of the much less certain fate of a given MVP. At the
| very least you'll have another tool in the toolkit to assess
| future project requirements, rather than blindly attacking
| everything w/ a hammer.
| cirrus3 wrote:
| Agree
| rubylark wrote:
| I'll add an anecdote to contradict that argument:
|
| I work in embedded, and the place I work restructured to have a
| dedicated software group. They hired young software engineers
| and focused on getting people who are good programmers without
| really caring what they were good at. Most people ended up
| being web developers and liked webstack.
|
| We were tasked with making a handheld air quality measurement
| device with a touch screen that could pair with a computer app
| that we would also write. Most people on the team knew webstack
| so we decided on a HTML/CSS/JavaScript +SQLite that would run
| in Electron Chromium on Linux on the physical device.
|
| So what went wrong? Well, electron is bloated for embedded
| devices and the mid-tier processor we were using chugged so
| much that it would get hot. Hot enough to affect the
| temperature sensors at the top of the board and throw off the
| gas density measurements. Our MVP was nearly done when we
| discovered this problem.
|
| We had two choices: throw out the hardware or throw out the
| software. We ended up throwing out the software and starting
| over (in Winforms + C# if anyone's curious). I and two others
| quit as a result. It is _really_ depressing redoing something
| you've already done in a different language.
|
| If we picked the lighter weight framework from the start
| instead of picking the language most people knew, we wouldn't
| have lost a year of work.
| sbarre wrote:
| Sure, but I suspect the motivation behind this post is
| specifically to learn about what people love to work with, not
| to be convinced about what to use for their own MVP?
|
| At least that's the value I'm getting out of everyone's answers
| that actually talk about their favourite stack (vs just saying
| "use what you want" etc)
| readonthegoapp wrote:
| This is always the wrong answer to this question.
|
| Yet it never goes out of style, apparently.
| FlyingSnake wrote:
| For an MVP the most important thing is to get the product ready,
| have early feedback and then iterate based on the response.
|
| After my extensive framework shopping of PHP/Laravel, Phoenix,
| Supabase, Directus, Kotlin+SpringBoot, I settled for
| Django+HTMX+AlpineJS for my side project. I could create a
| working MVP in a week and within 1 month I had most features up
| and running.
|
| I plan to host it on Oracle cloud (free tier) and have not seen
| any issues with it so far in the test runs.
| ch4s3 wrote:
| What made you decide against phoenix?
| x98asfd wrote:
| If you are already using postgres, then postgrest for backend,
| and solidJS for front end.
| japanman425 wrote:
| .net core on whatever is the simplest to get it to production.
|
| 99% of your projects do not need hyper scale and you are just
| engineering problems for yourself.
| sourdesi wrote:
| I've been working on a side project that aims to provide a really
| simple UX to spin up full-stack web apps with CI and scalable
| infra by default. The idea is that you would simply enter a
| domain name you want to purchase and then the tool would do the
| following:
|
| 1. Purchase the domain name using AWS Route53 (perhaps you'd need
| to setup an IAM role for the website to access your pre existing
| AWS acct)
|
| 2. Setup frontend, API, and CDK infra repos. All in TypeScript.
|
| 3. Frontend react, backend Api gateway backed by lambda
| functions. Have a graphql endpoint that talks to an Amazon
| auroradb. CI for backend and frontend is defined by a CDK package
| that is also deployed to the AWS account that also sets up the
| networking and database for you.
|
| 4. Have a basic layer of application code for setting up user
| authentication and storing user data in the aurora db.
|
| Basically my idea is it kinda sucks that everyone has to do all
| of this setup yourself if you want to start a new project. Or you
| have to rely on no-code tools like Squarespace etc which may not
| be what most engineers are looking for. Having something that can
| go from simply entering the domain name you want to scaffolding
| out a fully functional full stack web app with CI and serverless
| infra defined by code that can scale from day 1 seems both
| incredibly useful and doable.
|
| Curious to hear other people's thoughts on this!
| moltar wrote:
| Hey sourdesi, this is _exactly_ my stack too, and I am also
| dabbling with a starter. Would also love to discuss and
| collaborate. Please send me an email (see profile).
| zdwolfe wrote:
| Neat, I am working on something similar with almost all the
| same tech you mentioned (CDK, R53, TS, APIGW+Lambda), and a
| Dockerized dev env with everything set up. It's meant to be a
| boilerplate I copy for new side projects. DM me on twitter
| (same username) if you'd like to compare notes or collaborate.
| s-xyz wrote:
| Back-end: - Python 3.10 or 3.11 - Cloud functions 2nd gen as
| first choice (most pipelines & simple APIs) - Cloud run for (more
| advanced) APIs with FastAPI
|
| Databases - Firestore for front-end related data - BigQuery for
| Analytics
|
| Front-end - ReactJS with Hooks - MUI Material
| andronov04 wrote:
| supabase+svelte or nextjs
| hardware2win wrote:
| Linux VPS + C# + ASP NET Core
|
| If front needed then pure js or vue
|
| Database probably sqlite or postgres if that fits the needs
| moxplod wrote:
| Similar to what I use.
|
| I use .net mvc with a razor-templating engine. With pjax.
|
| It makes it super easy for me to maintain all my UX in server-
| rendered HTML templates. I get a clean SPA with super high
| development efficiency with MINIMAL javascript.
| pocket_cheese wrote:
| For an MVP I'm building, I'm using retool as the frontend, Flask
| hosted on appengine as the backend, cloud functions for async
| task execution, and a managed CloudSql postgres instance for the
| data layer.
|
| I suck at UI/UX design and don't want to write a bunch of JS for
| async webapp stuff, so retool is a force multiplier there and
| would highly recommend. I Don't want to manage any infra, so
| appengine handles that for me. After getting everything setup
| with terraform in a day or so, I spend all of my time developing
| core functionality and 0 time managing servers or getting a UI to
| do what I want it to do.
|
| Total cost to host is < $100
| h1fra wrote:
| Currently building an MVP:
|
| - NodeJS, Typescript, Docker
|
| - Fastify for the API
|
| - Sequelize for ORM (Prisma seems like a good choice too but
| comes with too many features imo)
|
| - Postgres (locally rn)
|
| - AtlasDB for migration (I like the declaration style)
|
| - Hosting didn't choose yet but would go with vercel or free tier
| GCP
|
| Im proefficient with JS so that explains the why, however in 10
| years the ecosystem still didn't catch with Rails in term of
| having one solution to all problems.
|
| You still have to carefully choose your dependencies, all
| tutorials are quickly outdated and it's missing some crucial
| pieces that you have to glue manualy or code entirely.
| sevenf0ur wrote:
| Prisma has screwed me too many times to count. Sequelize has
| always been solid.
| threeseed wrote:
| Scala + Scala.js
|
| The advantages of writing everything in the one language is
| massive.
| AlexITC wrote:
| Agree, I have been using Scala.js for many years and there is
| no going back to js/ts.
| sph wrote:
| I'm building an MVP solo.
|
| Rust for the core application, Elixir for the backend, frontend,
| API, data layer. Javascript is pretty much non-existent, all
| client-side interactivity is done by LiveView.
|
| Packaged into a podman container and deployed to a Hetzner
| dedicated server. Storage on PostgreSQL, probably the only thing
| I would rather not have to manage, but honestly single node is
| perfectly fine for an MVP. Provisioning is done with Terraform
| and Ansible.
|
| Future expansion (pretty far away, post launch and post paying
| customers) is add more geo-distributed worker VPSes, talking to
| the central coordinator via Wireguard link.
|
| Setup is pretty cheap, fast, scales really well, and it's easy to
| understand. With additional services (mail, monitoring, etc.)
| should be less than $100/mo all inclusive, and that should be
| enough for up to ~100 paying customers.
|
| I have no plans of changing any part of this setup for the next
| decade. I'm too old to want to get golden handcuffed to turn key
| solutions and cloud products that just introduce complexity and
| become VERY expensive, and badly documented, past the demo stage.
|
| Started in November, closed alpha release with users next month,
| launching Q2 2023.
| jstx1 wrote:
| If the backend, frontend, API and data layer are in Elixir,
| what's actually written in Rust?
| sph wrote:
| At the core there is a custom crawler written in Rust, with
| the goal of eventually releasing it as an open source
| standalone application.
|
| But everything else, including scheduling the execution of
| this crawler, and parsing its output, is done on the Elixir
| monolith.
| ElfinTrousers wrote:
| Would that be in Rust for performance reasons? Elixir IME
| isn't as slow as some other popular languages but it's no
| speed demon either.
| 0cf8612b2e1e wrote:
| A crawler should be limited by the network not CPU.
| Outside of the language making it easier to handle
| multiple concurrent connections, I doubt speed would be
| much of a consideration.
| kfrane wrote:
| I'm not sure, it might be. If you're not careful, CPU can
| become bottleneck when you have a 10Gbit network card.
| danudey wrote:
| Rust also has the benefit of eliminating a ton of classes
| of bugs, which is great for the core of a product that
| connects to the network, fetches untrusted content,
| parses it, and (presumably) stores it somewhere.
|
| Not that you can't still have bugs, but when you can get
| C-levels of speed with Python-levels of safety, why not?
| sph wrote:
| Performance has nothing to do with it. You can imagine
| the application being a very specialised version of
| `wget`, and I like CLI system applications to be easy to
| distribute, with no dependencies and not requiring an
| entire VM to run.
|
| Erlang/Elixir is good for networked servers. For CLI apps
| I either choose Go or Rust, and I much prefer the latter.
| Since I want to make this component open source, I wanted
| to keep it separate from the rest of the closed source,
| proprietary Elixir backend.
|
| There is no wrong choice to be honest, this is mine for
| my startup, and I don't think I need more justification
| than "I am productive with it for the task at hand."
| lairv wrote:
| How does Elixir interacts with the Rust code ?
| sph wrote:
| The Rust app is kept as a standalone application. Elixir
| spawns the process, passes it an internal URL where it
| can post its output, and forgets about it, since each run
| might take a few minutes to hours to complete.
| beckler wrote:
| Via native implemented functions aka NIFs.
| 0x008 wrote:
| But do you code in vim?
| newaccount2021 wrote:
| I love Rust and program in it a lot...but I would never use it
| for an MVP
|
| Rust is the tool you use when you are done prototyping, not
| when you are just beginning
| earthling8118 wrote:
| Hard disagree. Rust lets me move much more quickly in many
| scenarios. I wouldn't want to prototype in Python for
| example. In my experience I'll spend too much time debugging
| and dealing with typing issues if i did that. Even with type
| hints. Having solid tooling that I can trust to help me
| maintain quality while moving fast and a really good
| ecosystem makes Rust a good choice
| smaddox wrote:
| Depends what you're prototyping. Rust is hard to beat for
| prototyping an interpreter, for example.
| leros wrote:
| I like using ExpressJS with Typescript and a Postgres database.
| There are lots of great hosting options, but I'm using Heroku
| right now.
|
| I do really like the Firebase/Superbase options, but they impose
| restrictions and I don't like having restrictions like that
| unless I know for a fact that I'm building something very simple.
| eddieroger wrote:
| The Supabase folks are very active on here - if you shared your
| restrictions, maybe they'll open the up.
| kiwicopple wrote:
| (supabase ceo)
|
| We definitely like to receive feedback for improvement. let
| us know what you're frustrated by @leros.
|
| Sometimes there is context for the restrictions which we
| haven't shared in the docs, so it would be great to hear it
| so that we can either fix or clarify.
| leros wrote:
| I'm not unhappy about anything in particular. Superbase is
| fantastic and many of the upcoming things are things that
| I'm excited about.
|
| It's just that something I plan to work on for a long time,
| with lots of people, and that will have lots of business
| and scaling complexity, I prefer to run my own simple stack
| so I have full control and don't find myself waiting on
| someone else's roadmap for a feature I desperately need.
| yusufnb wrote:
| So many good answers, and interesting to read the overall
| technology landscape. The technology debates can be endless,
| though. I think it's good to consider a few non-technical aspects
| as well for selecting your stack -
|
| 1. Is this stack popular among recent similar successful
| products?
|
| 2. What technology will make it easier to find relevant talent?
|
| 3. Does your stack allow for rapidly changing code along with a
| rapidly changing team? This is important, especially in the early
| stages of development.
|
| 4. Are you trying to do things the Google way? Facebook might
| never exist had they started with C++ instead of PHP.
|
| 5. Do you want to be on the cutting edge for the sake of being on
| the cutting edge?
|
| I elaborated on this a bit in my blog here if interested -
| https://sleeksky.com/blog/technology-stack
| spamizbad wrote:
| Backend? Probably Python w/Pyright (Type-checked Python),
| FastAPI, Postgres.
|
| Reasoning is pretty straight forward: I know it quite well and
| it's easy to grok and hire for them. Good tooling and ecosystem
| around it. Are there better languages out there? Sure, but Python
| has the advantage of being wired into so many different business
| and scientific domains its impossible to paint yourself into a
| corner.
| michilehr wrote:
| I would use a full stack framework so I do not have the overhead
| of creating API endpoints.
|
| I would use Laravel with Livewire.
| matijash wrote:
| You might also want to check out https://wasp-lang.dev/ - it
| lets you use React & Node.js (although it seems you prefer
| php), but you don't have to write API endpoints + everything
| works out-of-the-box
|
| (disclaimer: I'm one of the main contributors to the project)
| michilehr wrote:
| Thank you for your reply matijash!
|
| I am not tied to a language. wasp looks very cool and will
| definitely try it out on the next educational day at the
| office!
| matijash wrote:
| nice, thanks for giving it a look! Btw, what is an
| educational day? You get to spend the day learning
| something new?
| oscargullberg wrote:
| Depends a bit on the system, but for a fairly simple webapp:
| hasura, sveltekit, firebase auth and some lambdas
| Gud wrote:
| Same as always - FreeBSD, SQLite and Flask
| sheikheddy wrote:
| People reading this for inspiration on what stack to use should
| keep in mind that the best stack is the one they'll actually use.
| EZ-E wrote:
| [flagged]
| EamonnMR wrote:
| Postgres, Sqlalchemy, FastAPI, Nginx.
| seinecle wrote:
| 5. JakartaEE for the backend, Jakarta Faces + Primefaces for the
| front end, redis for the db, Javalin if API endpoints must be
| provided. Hetzner server. Only pain point would be the NGINX
| config, always non trivial.
|
| Why? Very simple, fully featured, ready to scale.
| LeonenTheDK wrote:
| Well that depends a bit on what the MVP needs to be.
|
| Anything web related I'm probably going the Elixir/Phoenix route.
| I'm no web dev, but this combination makes me actually kind of
| like doing web-things with how batteries included it is, and the
| tools it provides to really jump start a project. Then I'd host
| it "old schoolish" in a VPS or similar since that's what I know
| best. Might consider being fancy and investigating if Fly is a
| good fit. If a DB is required I'd use SQLite unless some
| constraint pushes me into Postgres.
|
| If we're talking command line tool, the correct answer for me
| would be C# since that's what I know best. The answer I'd want to
| give though is Go since I want to get deeper into it, but that's
| not a good business decision.
|
| Desktop application, best I've got in my kit is WinForms with C#
| and prayers that it never need run on anything but Windows. Maybe
| Linux with some Wine trickery, but that's not something I've done
| before either.
| mrdoops wrote:
| Agreed Elixir/Phoenix + Tailwind is at the sweet spot of
| scalability, performance, and bonkers productivity.
|
| Real time? Need to go distributed? Maximize # of features /
| developer bandwidth? Cutting edge machine learning training &
| model serving?
|
| Mobile? JSON APIs and GraphQL tooling is great, but
| https://github.com/liveviewnative is moving fast so this stack
| almost has the exodia of full stack, one language, and
| distributed actor model based scalability.
| LeonenTheDK wrote:
| Honestly I continue to be amazed with each year of
| developments. The increased robustness of the greater Elixir
| ecosystem is unreal. The best part to me too is despite how
| active it all is, progress overall is very measured and sane.
| It also doesn't develop at such a pace that it feels
| exhausting to keep track of, despite all the great work.
| j-krieger wrote:
| What I like about elixir is that it feels like developing
| with javascript, but you're not delivering megabytes of js to
| the client
| el_nahual wrote:
| LiveView is great but IMHO it's easily abused. "No JS, ever" is
| a mistake. IMHO it works best when there's very clear rules
| with where one should use LiveView vs JS.
| nelsonic wrote:
| Totally agree! For almost all web-based MVPs the PETAL Stack
| (Phoenix with LiveView & TailwindCSS) deployed to FREE Fly.io
| is an epic choice for both response times, realtime features,
| dev speed (time to market). We're currently building our MVP
| with it and it's fully Open Source so anyone can learn from our
| journey: https://github.com/dwyl/mvp
| danielvaughn wrote:
| Never heard of phoenix but sounds interesting. What's the
| persistence layer of the stack?
| finder83 wrote:
| Typically Postgres
| stevenhuang wrote:
| I really wanted to like LiveView but starting from 0 in the
| Erlang world meant learning a whole bunch of language
| semantics and idioms.
|
| In fact I found it perhaps harder to get started than
| learning Rust, especially because the language server seemed
| unable to offer as rich completions compared to Rust.
|
| In the end I did manage to understand most of the primitives
| and concepts in the basic sample app, but it did make me re-
| evaluate if it is the best choice in terms of technology
| adoption when it departs from most typical Python/JS/C family
| style conventions.
| LeonenTheDK wrote:
| I can sympathize, it was a huge jump for me coming from C#
| land, and I see this sentiment repeated a bit for newcomers
| so it might be the nature of the beast.
|
| I definitely wouldn't recommend it for an MVP if someone
| isn't already into it, but then I don't think MVPs with
| tight business requirements are generally a good place to
| explore new technology anyway. I think there's a lot of
| room for nuance there though.
| nelsonic wrote:
| Totally agree that the learning curve can feel steep
| learning Functional Programming style, Elixir Syntax and
| Phoenix framework in one go. But if it's any consolation,
| our company has taken people who only JS or Python and got
| them fully up-to-speed in less than a week using the
| open/free tutorials we've written:
| https://github.com/dwyl/technology-stack HN feedback very
| much welcome.
| stevenhuang wrote:
| That looks like a fantastic resource, especially
| appreciate the update you've provided here
| https://github.com/dwyl/learn-elixir/issues/102
|
| I'll definitely have to keep at it and play around more,
| thanks!
| veqq wrote:
| Thanks for this link, I'll give it a go!
| ufmace wrote:
| I'm 90% on Ruby on Rails dockerized. Meaning I would almost
| certainly choose that absent a very good reason to use some other
| backend stack. Rails because it's highly battle tested and
| flexible and good enough for almost anything. Dockerized because
| IME setting up and maintaining a Ruby environment with up to date
| version on bare metal is highly painful. Docker lets me be much
| more consistent with both Ruby versions and the rest of the
| server config.
|
| I'm less solid on the deployment. Could go with one of the
| commercial docker-y hosting systems, or a commercial K8s setup,
| or a hand-rolled Docker host via Ansible. I've done all 3, and
| I'm not sold on any of them being the best for everything.
|
| Front-end side is more flexible depending on the type of
| site/business. Normal ERB-style SSR is probably fine for a lot of
| things with a few sprinkles of basic JS. Would re-explore if I
| thought it needed a proper front-end app. React is neat, but
| darned if every single time I try to do a version bump on a small
| React app, I end up needing to rewrite half of it.
| MattyMc wrote:
| Vanilla Rails.
|
| My app started 7 years ago with Rails + AngularJS on the front
| end. Wish I had just used Rails for 90% of what I had used
| AngularJS for.
| champagnepapi wrote:
| full a full stack web app Backend: Postgres Go Frontend:
| Typescript React, with React Query Tailwind for styles
|
| Why? Because i know these technologies fairly well.
| aantix wrote:
| I built Call Stacking ( https://callstacking.com/ ), a modern
| Ruby on Rails debugger, with Jumpstart Pro and 1.5 hours a night
| over the course of 4 months.
|
| We have four kids, host an exchange student, a new puppy. Our
| schedules are _full_.
|
| Nothing compares to the productivity of Ruby on Rails. Especially
| when coupled with a high-end template like Jumpstart Pro (
| https://jumpstartrails.com/ ).
| mooreds wrote:
| I used something similar ( https://bullettrain.co/ ) in the
| past. Have you taken a look at that? Bullet train used to
| charge but now are apparently open source.
| aantix wrote:
| I haven't personally used it, but it looks like a really
| solid choice as well.
|
| I know of Andrew Culver through Twitter and he seems like a
| genuinely nice person.
| roflyear wrote:
| When I click examples why don't I see code?
| adrianthedev wrote:
| Next time check out Avo. It integrates perfectly with Jumpstart
| (or any Rails app) and helps you create a back-office app in
| no-time.
|
| https://avohq.io
| aantix wrote:
| I've checked out Avo several times before. I don't need it
| quite yet.
|
| It looks beautiful Adrian.
| cebu wrote:
| Currently building with Next/TRPC/Prisma/PG and would choose it
| again. I might be a little slower than starting with a full-
| featured MVC kit like Laravel or Rails, but having an e2e type
| system is so worth it to me. I do miss having a more mature ORM.
|
| I'm constantly tempted by Phoenix but desuaded by the lack of a
| type system. Does elixir somehow make up for the lack of types as
| a functional language? Also, I can reuse a good deal from my
| current stack in a react-native app for mobile, which I'd miss
| out on in another framework.
|
| Wish I could say Flutter, but have not been impressed by the web
| experience.
| karmajunkie wrote:
| There's a component called dialyzer that can help detect type
| issues, but i wouldn't say its nearly as useful as having real
| types in a language. That said, I've never found it to be much
| of an issue in Elixir, and the advantages you get with BEAM are
| worth it. There's a newer language called Gleam that does have
| a strong type system you may want to investigate, as it runs on
| BEAM (like Elixir and Erlang) and can use libraries and
| applications from both in its apps.
| Dnguyen wrote:
| I currently use Remix Prisma SQLite Mantine Keep it simple so I
| can move fast
| noodle wrote:
| Rails on postgres with React in the frontend is my default swiss
| army knife. I know Rails well and it still gets stuff done fast,
| comparatively speaking. If the problem space I work in requires
| something different or solves the problem better than Rails, I'd
| switch.
|
| Edit: post-mvp, I'd stick with Rails still unless there are
| specific difficulties with it. But I've yet to have major issues
| building a large Rails team/project, including present day.
| heeton wrote:
| For almost everything it's Elixir at the moment.
|
| Phoenix is wonderful for web apps, LiveView makes UIs about 2x
| easier and faster.
|
| For more interesting electronics MVPs I still use Elixir + Nerves
| for prototyping.
| theptip wrote:
| These days with Hotwire and HTMX, you can go very far with
| Django/Rails (and I suppose Elixir too). Not having to write an
| API for your webapp to consume is huge.
|
| Until you actually have reason to scale (eg you are building
| WhatsApp), building to optimize the productivity of your
| iteration cycle usually gives the best payoff for pre-PMF
| projects.
| bob1029 wrote:
| > Not having to write an API for your webapp to consume is
| huge.
|
| This is something that is so understated. I use Blazor to
| achieve similar semantics in many .NET codebases.
|
| The speedup you get by pulling the client state into the server
| is incredible. The time savings is easily measured in thousands
| of hours at this point. It's almost like working with old
| school PHP again, but you get all the 2-way stuff as well.
| eloff wrote:
| I'm doing one right now.
|
| Using Rust, Diesel(Orm), Postgres, compiled jinja2 templates
| (Askama), and a smattering of JavaScript with AlpineJS, and
| Tailwind. I have 100 loc JavaScript that makes it easy to replace
| only parts of the page via Ajax calls.
|
| Really simple stack, really lightweight, a joy to debug, and runs
| instantly. The delay on my dev laptop is below 10ms, it's
| undetectable.
|
| So much better than React and Python that I use at work in nearly
| any dimension. I hope the mvp works out and I can quit that job
| one day.
| likeabbas wrote:
| Backend: Rust + Axum/Tonic
|
| Frontend: If webapp needed, Typescript + React. If just html
| templating, probably Yew
|
| Database: PostgreSQL. Move to Yugabyte or Scylla if scale becomes
| needed.
|
| Streaming/event driven architecture: Fluvio
|
| Cloud: AWS
|
| Servers: ECS/Fargate to start. Move to Kubernetes as needed
|
| IaaC: CDK
|
| Repository: Github Monorepo
|
| CI/CD: Unsure.
|
| Style: Monolith API server. Separations will be made through Rust
| modules and interfaces. For anything that requires dedicated
| CPU/threads, those will be moved to separate services to be
| called by the monolith via gRPC.
| rozenmd wrote:
| Build with what you know, that way you'll be focusing on just
| building what your customers are asking for, and not also having
| to learn the technology as you build.
| mindcrime wrote:
| Exactly. If one were to look at my top-level reply here and ask
| "why?" for any item I listed, in basically every case the
| answer would be "It works, and I know it." I could get more
| done faster using that stack than a stack I'd have to learn
| from scratch.
|
| That said, there's a time and place for experimenting and
| learning new stuff. And I _am_ interested in trying Elixir at
| some point. But to "get stuff done" in the near term? Yeah,
| it's going to be mostly Java/Groovy, Grails, and some
| Javascript. Hell, I might even break out jQuery just out of
| sheer familiarity, if I got stuck doing something using vanilla
| JS.
| hedgehog0 wrote:
| I was wondering is there anyone uses Clojure or other Lisp
| languages for these kinds of things...
| milt wrote:
| I do! Clojure and Pedestal https://github.com/pedestal/pedestal
| work great for quick MVPs. Clojurescript with a nice HMR
| environment like Figwheel https://figwheel.org/ is also great
| if you need a front end.
| lummm wrote:
| I think I'd have to say NextJS with SQLite. Every DB table would
| just be 'id' and 'data', where 'data' is JSON-encoded and the
| schema is only enforced in code. This lets you write a 30-line
| ORM. Foreign-key relationships are just modelled as lists. If
| speed is the major concern, I find this the fastest way to build.
| You can bring structure to the DB as things are nailed down.
| dbbk wrote:
| Why would you need to do this? It's not like creating tables
| with columns is a time consuming endeavour
| adrianthedev wrote:
| Nothing really beats Rails. Use something like Jumpstart
| (jumpstartrails.com) and Avo (https://avohq.io) and you scaffold
| a full consumer-ready app in literally a few hours.
|
| The thing that bugs me the most with Next.JS and the whole
| JAMStack movement is that, yeah, you get from "git clone" to
| deployed on Vercel in two minutes, but if you need to create real
| app features like a sturdy admin, accounts, authorization, proper
| asset management, CI/CD, it takes a whole lotta time. I'm not
| even touching the most common app features. I'm speaking from
| experience, from building a Next.JS app for about a year.
|
| Most Next apps out there are incomplete with the worst freaking
| user experience. Insert any other JS framework or hosting
| provider in the place of Next.JS and Vercel.
|
| Of course, this is a generalisation, not all Next apps are that
| bad.
|
| Using Rails is like a cheat-code in dev term.
| lcnPylGDnU4H9OF wrote:
| Thanks for making Avo! I'd been building something similar in
| the application I'm currently working on and it was nice to
| have something that already figured out much of the hard stuff
| to replace my shitty implementation.
| adrianthedev wrote:
| Great to hear! Let me know if you run into issues.
| robertakarobin wrote:
| I'd run an API using Deno (https://deno.land), and consume that
| API with an SSR/SSG site built using Astro (https://astro.build).
| SCSS for styling, and probably just Vanilla JS (written in
| Typescript and compiled via Deno) -- I increasingly find that
| unless my site is massively interactive, plain old Vanilla JS is
| totally sufficient.
| verisimilidude wrote:
| It really depends upon the product, right?
|
| Let's assume we're talking about a web-based business app.
|
| If the MVP already requires some complex business logic, then I'd
| probably choose an old-school stack. I personally prefer Rails.
| But I'd probably pick .NET. Above all, my metro area is full of
| .NET people. It'd be much easier to find/hire collaborators in
| .NET. I'm comfortable and productive enough with .NET on the
| technical level.
|
| However! If I could get away with just putting up a couple Lambda
| functions, then that's absolutely the path I'd choose. It's an
| MVP. Let's get this boat rowing ASAP!
|
| In short, product and market influence the best technical
| approach.
| idontwantthis wrote:
| Nest JS and Typescript on EC2. MongoDB for database.
| happytoexplain wrote:
| As somebody trying to learn the web stack, reading this thread
| makes me a little sick to my stomach.
|
| Edit: Thanks for the advice!
| yamtaddle wrote:
| They're all basically the same, some are just more or less bad
| and some have more or fewer very-helpful libraries available.
| It's all doing the same shit, mostly in very similar ways.
| bluefirebrand wrote:
| Don't worry too much about all of the options.
|
| Pick one stack and learn it. The concepts are all
| transferrable.
| greggeter wrote:
| [dead]
| owenmarshall wrote:
| I've only recently come back to the world of web after doing
| mostly devops/backend stuff.
|
| While getting on the JS framework treadmill might get other
| people hired, staying server side + Bootstrap kept me sane and
| productive. The only place where I spent an innovation token[0]
| was on htmx and so far it's been absolutely worth it.
|
| [0]: https://boringtechnology.club
| profstasiak wrote:
| what backend do you use?
| owenmarshall wrote:
| That gave me the biggest thing to think about. I had the
| most web experience with Django but it's been _years_ since
| I used it in anger. In the meantime I 'd been using FastAPI
| and knew enough of its warts, so I went with FastAPI +
| Postgres.
|
| But if I was just starting out trying to learn a web stack
| like GP, I'd say absolutely don't pick FastAPI, use Django
| + Postgres + Bootstrap + htmx and you'll be happy.
| zkirill wrote:
| Don't think about it too much. Most of the web still runs on
| plain old PHP and HTML. New technologies pop up every now and
| then but most people who do this professionally just want
| something that does the job and don't talk about "their stack"
| outside of work hours.
| simonbarker87 wrote:
| Typescript, Tailwind, NextJS, Supabase, Vercel and you just can't
| go wrong.
|
| If I needed a long running server for whatever reason I'd
| supplement Supabase with a NestJS app.
| logifail wrote:
| > What would be your stack if you are building an MVP today?
|
| Many years ago a CIO told me he didn't really care what
| technologies I picked for an upcoming MVP backend, as long as I
| was already comfortable with them and would therefore be
| productive quickly.
|
| He also told me we would almost certainly need to rewrite
| everything _at least once_ , so not to dwell too long on the
| initial stuff.
|
| Build the MVP, build it quickly, get it in front of users. It
| just needs to work, you're not going to get marks, or customers,
| for backend coding style.
| noveltyaccount wrote:
| This is excellent advice. The "worse is better" manifesto says
| similarly:
|
| > The lesson to be learned from this is that it is often
| undesirable to go for the right thing first. It is better to
| get half of the right thing available so that it spreads.
|
| https://www.dreamsongs.com/RiseOfWorseIsBetter.html
| throw1234651234 wrote:
| That CIO is brilliant. That's the kind of wisdom you get with
| experience. Always good when stakeholders ask for additional
| features because the MVP isn't completely throw-away and then
| my team doesn't know the language. Then they learn the
| language, but we need to hire new devs and grow, and no one in
| the market knows the language. I always tell the new hires that
| we have a lot of learning opportunities - Go, Ruby, Python,
| Elixir - you name it. All the fresh college grads can't wait to
| jump in and contribute within 2 hours of getting hired. My
| grand-grand father always said "If you can't pick up a new
| language in a day, you aren't a good programmer and don't
| belong on Hacker News." He also said using C#/Java/Python is
| "sus booomer ** fr".
| JohnBooty wrote:
| He also told me we would almost certainly need to
| rewrite everything at least once, so not to dwell too
| long on the initial stuff. Build the MVP, build it
| quickly, get it in front of users. It just needs to
| work, you're not going to get marks, or customers, for
| backend coding style.
|
| 1000% agree. Overengineering things is the death of MVPs. But
| man this is hard to do in many real world situations.
|
| Stakeholders and managers want you to keep adding incremental
| features. Never had a situation where they were like "okay,
| cool MVP, see you in a few months after you tear it down and
| rebuild it 'for real'."
|
| That "build a fast crappy MVP" mentality takes serious buy in
| from stakeholders from day one. That mentality might be common
| in SV and other startup communities but boy is it tough to find
| elsewhere.
| taeric wrote:
| Agreed, but it is also easy to see the tension in your second
| paragraph. You can plan to rewrite everything at least once,
| but you will never get that actually in the plan.
|
| My only somewhat clear path out of it is to make sure you
| built it so it will be easy to rewrite. Either do the least
| that you can, or keep an eye for improvements, but don't
| necessarily act on them.
| topicseed wrote:
| Golang backend, Sveltekit frontend, and Openapi in-between with
| codegen on both ends to type it all (and document) throughout.
| gregors wrote:
| Phoenix/Elixir/Postgres Vue/Liveview
|
| Phoenix support for websockets is really good right out of the
| box and for small/medium complexity UI's Liveview is light years
| faster in dev time than a spa. Liveview can take you far, but
| heavy UI work I still default to Vue.
|
| Elixir can take some time to wrap your head around since it's a
| major shift from more mainstream programming languages, but I
| think there's a ton of fun in that.
| matthewsinclair wrote:
| If I was starting from scratch and didn't have any other
| constraints, I'm sure that I would go with Elixir/Phoenix.
| jamil7 wrote:
| FastAPI & Postgres for the backend. REST + websockets for the
| API. Over the years I've tried all kinds of BaaS and more magic
| "X as a service" solutions, but I often hit some edgecase or
| limitation that is a dead-end or run into some bug I can't fix
| myself. So I prefer the flexibility and robustness of Postrgres
| with the ecosystem of Python.
| AYBABTME wrote:
| Rails or NextJS on Vercel/Fly/Netlify/wtv, with PlanetScale for
| the DB. That's it.
| physicsguy wrote:
| Django, in my previous role we did MVP websites for academics and
| the speed of getting a site up and running and deployed was just
| so fast. I've never worked with anything else that is as fast,
| anything like FastAPI or Flask or Express or similar either
| requires additional libraries to add really basic and common
| functionality or you have to roll it yourself.
|
| I personally don't think that if you're building an MVP you
| should be worrying that much about how to store users in the
| database and add RBAC and building a way to add middleware and a
| storage layer and all of that crap. It's not worth it, your
| application is not a special snowflake.
|
| Edit: Should say that with that I mean serving HTML via Django.
| Usually I would use Bootstrap for layout. Very occasionally I'd
| add an API for some interactivity but I think for most MVPs
| interactivity is likely to be a secondary concern until later.
| FlyingSnake wrote:
| Came here to say this. I have a side project that I need to
| spin up quickly and after lots of framework shopping, I settled
| for Django.
|
| Django and it's batteries included philosophy is perfect for
| creating full stack applications. The best thing about Django
| is that almost every problem you face has been answered by the
| community.
|
| The community tools like DRF/Django-Ninja/Crispy-forms/Django-
| environ etc are top notch and it's very easy to extend your
| application.
|
| 7/5 would use Django again.
| cushychicken wrote:
| >The best thing about Django is that almost every problem you
| face has been answered by the community.
|
| This is something I realized pretty quickly when toying with
| migrating my side project from Flask to Django last year.
| Everything I wanted to know how to do, I could google with
| "Django" as the first term, and figure out how to accomplish.
| Anything that took longer than 2 mins to figure out how to do
| was generally a matter of not knowing how to phrase the
| question.
|
| It's made me a huge Django advocate.
| bastawhiz wrote:
| The biggest benefit to Django, in my opinion, is the orm and
| admin tooling. Being able to fix things in your app without
| having to open a repl or open a database tool is absolutely
| killer.
| danudey wrote:
| I honestly cannot believe that Rails doesn't have this built
| in. This was something that was in Django for as long as I
| can remember; I was looking at it in I think 2006 and it
| existed at that point in a very similar state to what I've
| seen lately.
|
| Not a dig on Rails, like "Oh, Rails is so bad they don't even
| have..."; rather, Rails is extremely capable, and so are
| Rails devs, so I legitimately don't understand why this isn't
| there already, 15+ years after Django.
| treis wrote:
| Rails has Active Admin which is equivalent to what you get
| with Django. It's just not a core Rails gem but it's one
| line in your Gemfile to add it.
| dieselgate wrote:
| Whoah I never knew that - or maybe did but never
| seriously considered it. It's been my biggest surface-
| level gripe with Rails compared to Django so thank you
| very much for bringing it up
|
| Edit: and it' still maintained !
| jamie_ca wrote:
| There's a handful of very capable and mature admin
| solutions (activeadmin, rails_admin, administrate, and
| still people coming up with new ideas, see avo and madmin
| as newer examples), they just haven't had one become
| bundled mainline.
|
| Similar situation with authentication, where devise has
| been a mainstay for over a decade, but it's not always the
| best fit for everybody so core rails still just has the
| basic plumbing to build it yourself (with the low-level
| has_secure_password).
| DwnVoteHoneyPot wrote:
| To be fair, Django only caught up with Rails in the past 5
| years. When I started with Django it didn't have basic
| stuff that Rails had, such like auto database migrations
| and the Rails asset pipeline. The database migration stuff
| really helps when building/iterating. The Django middleware
| was very finky at the time.
| slig wrote:
| FWIW, Django has built in migrations since 1.7 which was
| released in Sep/2014.
| D13Fd wrote:
| This is where I came out a couple of years ago. I love Django
| and it has worked out perfectly. But I'm far from an expert.
| jononomo wrote:
| The Django Book is phenomenal. It is just so well-written and
| so clear that it makes my heart ache: https://django-
| book.readthedocs.io/en/latest/introduction.ht...
| DwnVoteHoneyPot wrote:
| Another good one is Tango with Django.
| https://www.tangowithdjango.com/
| iamsanteri wrote:
| I'm trying to learn Django just for this kind of MVP purposes.
| I also did a small mini project in RoR by following their
| documentation. Is there anything that is significantly easier
| to do in RoR vs. Django? Alternatively, is there anything, say,
| on a larger scale that I can do with RoR that I cannot do in
| Django if the project grows? These are the questions I've been
| wrestling with quite a bit now. After learning Vue and React.js
| and having used and being cognizant of Next, Nuxt, Supabase,
| Firebase and all that other stuff, I'm looking to become a bit
| of a better developer by understanding the intricacies of
| traditional monoliths and how problems are solved on the
| backend. I'd also like to be able to serve predictions and host
| ML models in production. Likewise, if my MVPs catch on, I'd
| like to retain majority of my "IP" by the means of Django or
| RoR. Any intuition perhaps on my above questions? Thx!
| mlboss wrote:
| If you thinking of anything closely related to ML then
| python/django is the way to go.
| FlyingSnake wrote:
| My 2c.
|
| Django shines at creating a nice project scaffold with all
| the things you need to do rapid development. It has first
| class support for DB, unit testing, schema migrations, good
| enough templating system, performant ORM and can be easily
| debugged. The documentation is top notch and the best thing
| is the community. Due to its longevity I found that almost
| all the issues I had were resolved by a simple Google query
| or visiting the docs.
|
| It's very easy to add functionality like social auth with few
| lines of code.
|
| I've also not found anything like Django admin in any other
| framework. I would highly recommended Django for an MVP.
| physicsguy wrote:
| My view on this is that there is little between them so in
| that case it's better to look at availability of skills you'd
| need to take it forwards in the operating region. For e.g. if
| it's easier to hire Ruby developers then choose Rails.
|
| I see a lot of people talking about Elixir, etc. on this
| thread, but I'm based in the U.K. and I've never seen a
| company locally using Elixir so even if it's really cool,
| it'd be a bad idea for me to choose it absent a very very
| good reason. If I choose Django then even if I can't find a
| Django developer, I can likely find people who know Python
| and the barrier to entry is pretty easy.
| iamsanteri wrote:
| Thank you for such a great and senseful answer!
| nelsonic wrote:
| Several companies in the UK use Elixir including the BBC,
| USWitch and the NHS! The London Elixir Meetup
| https://www.meetup.com/elixir-london/ has 1,467 members and
| is great place to meet fellow alchemists and learn
| interesting things!
| physicsguy wrote:
| I'm not in London ;)
| nelsonic wrote:
| Noted. but responding to the "UK" comment; London is
| often a good guide/proxy for the UK tech scene. But for
| reference: there are quite a few universities in the UK
| where students are learning & using Elixir for
| distributed/embedded computing projects so these people
| will gradually filter through into the workforce.
|
| Also there are plenty of Ruby/Rails Devs who have
| embraced Elixir/Phoenix.
|
| But it's a classic network effect problem; adoption
| drives jobs which drives learning and further adoption.
| Without a big corporate sponsor like a FAANG co,
| Elixir/Phoenix doesn't have the mindshare of other
| languages/platforms.
| [deleted]
| scrollaway wrote:
| Nowadays, Django has an _amazing_ library which is a lot like
| FastAPI but in the Django ecosystem.
|
| https://django-ninja.rest-framework.com/
|
| It's absolutely wonderful. I would use that in a MVP, and do
| the F/E in NextJS + Typescript.
| physicsguy wrote:
| I'm familiar with it, and I don't _love_ DRF but the downside
| with Ninja is that you end up writing a lot more boilerplate
| IMO. Unless you're strongly optimising for performance (and
| usually latency and the database are the biggest issues
| there), you can get away with ModelSerializer and DRF
| ViewSets a lot of the time for APIs and write very little
| code.
| nikanj wrote:
| LAMP because I'd like to focus on building features, not
| wrestling with the build tooling to get the dependencies of my
| dependencies dependencies compiling.
| gloosx wrote:
| 1. k8s 2-node cluster on cheapest instances
|
| 2. Hosted Postgresql
|
| 3. Hosted Graphql API layer microservice (like hasura)
|
| 4. Hosted hhtps server
|
| 5. Some kind of cloud storage solution
|
| 5. Load-balancer ingress
|
| 6. Some kind of CDN
|
| Spinnable in less than day with SSL on, works perfectly for any
| app to scale and covers most production problems
| RangerScience wrote:
| Rails if I want a database, Sinatra if I don't.
|
| Ruby just... wants you to be happy while you're using it. And in
| the long run of life, that matters.
|
| Python wants to be correct, Java wants you to not make mistakes,
| JS is still figuring itself out, Scala wants to do hard things...
|
| Ruby wants you to be happy.
|
| IMO - There's a lot of _very_ worthwhile follow-on effects of
| that - everything from libraries (generally) being just that much
| easier to get going with, to lower-stress teams having better
| communication, to _debates_ instead of _fights_ (I 'm looking at
| you, PEP572). Ruby is nice so we are nice :)
| mkraft wrote:
| I was a Rails, Sinatra, Ruby dev for years and I've been work
| with Go for years too. I'm struggling to understand your
| perspective because I'm no less happy coding in Go.
| RangerScience wrote:
| I've only done a bit of Go. I liked some of the ideas that
| were present, but ultimately (and I believe explicitly) Go
| has computer-sciencey-correctness goals (hence all the
| kerfluffle over generics) that, now and again, trip things
| up.
|
| Sometimes that's really nice - we had a handful of tiny
| utilities written in Go, like a format converter for use in a
| datastream - other times it gets in the way. I don't think
| I'd want to code up something large in Go, although it's not
| something I've had the opportunity to try.
|
| AFAICT, Go believes in _preventing_ you from making certain
| mistakes. And usually, within it 's context and paradigm,
| it's correct to do so. The problems arise when your problem
| domain doesn't line up well with that context and/or
| paradigm, which sometimes just comes down to the time you can
| spend on the issue.
|
| Another example: IMHO, all the weird issues Go was having
| working out how to do package management stems from some
| (admittedly very cool) ideas about Correct And Proper Package
| Management. I can't remember the last time I had an issue
| with gem management / bundler ( _except_ for the perennially
| awkward PG gem issue).
|
| It's a 85% vs 95% thing, and IMO that straight-up comes from
| having other priorities. There's a lot of overlap between
| "developer happiness" and "computational correctness", but
| it's not exact, and that comes up in few, but enough, places.
|
| Maybe another good example is Ruby array arithmetic. It makes
| no bloody sense from a math/CS perspective, but _goddamn_ it
| is handy in applications. So if your language is aiming for
| computational correctness, you 're not going to get that tiny
| bit of joy.
| mark242 wrote:
| * Whatever you already know
|
| * And has good IDE support for opinionated formatting
|
| * And doesn't require a ton of setup-to-build effort (ie, no
| debugging your build tools)
|
| * And has a quick pipeline from local development to production
|
| That's it. Language, database, framework, it doesn't matter as
| long as you meet those four criteria.
| jrvarela56 wrote:
| Personally big on Rails (use it at work every day). But, my last
| MVP I did with TS/Next/Mantine/Supabase/Vercel.
|
| Reasons:
|
| - I've been using Rails as an API only, so having to grok views
| felt like a waste. My React skills made me feel that learning how
| to make complex views in my backend was a waste of time.
|
| - One type of bug I hate is ensuring my API calls have the right
| schema. With Supabase and TS in the frontend, this is a non-
| issue: export types from db schema and all frontend requests are
| typed.
|
| - Supabase is something for sure: I had been eyeing it for a
| while now, and it did not disappoint. Getting endpoints - even
| with realtime updates/subs in the frontend - after just defining
| a schema is magical.
|
| - Auth is super simple with RLS - all this uses my SQL knowledge
| and makes me double down on it, which seems like a sane choice
| given it's been around for decades.
|
| - Mantine gives me a large list of prebuilt components. This
| isn't exclusive to this stack but would highly recommend using
| something like this instead of just Bootstrap or Tailwind on its
| own.
|
| Overall I'm happy with the results, feels way faster than my
| React/Rails workflow. Way less time in the backend (models,
| migrations, presenters, etc), more focus on tweaking the product.
|
| Con: does not move me in the direction of using Python more. Feel
| like this is going to be a must-have for AI-powered components.
| bottlepalm wrote:
| Same, Next.js, Vercel, Prisma, Supabase. I push to my GitHub
| repo and the site is live and deployed in less than a minute.
|
| With the stack you can use the same language, DTOs, libraries,
| etc.. both server and client side.
|
| Server side rendering ensures a graceful handoff between server
| rendered state and the resulting app state on the client.
|
| I'm also using MUI which includes all the components you need
| for a front end app.
|
| I also just really like react/JSX, very strongly typed coupling
| between the html and JavaScript. Makes it very easy to refactor
| and pull out new components with confidence.
|
| I really think this is the best stack for an MVP CRUD app right
| now. Interested to hear of anything better.
| jrvarela56 wrote:
| Ah you comment about MUI reminded me to include Mantine, also
| big productivity driver.
| 0xblinq wrote:
| This stack is pretty incomplete for most MVPs, as unless
| you're building something trivial like a landing page, you'll
| probably at some point also need libraries or a custom
| implementation for:
|
| - Validations
|
| - Translations
|
| - Error and request logging and auditing
|
| - Security (CQRS, CORS, CSRF)
|
| - Permissions and a way to integrate it with your
| authentication (does supabase handle this? don't know)
|
| - Email sending
|
| - Background jobs
|
| - Caching
|
| - File uploading
|
| - Rate limiting
|
| - ...
|
| Every time somebody suggests "just" Next.js, just "Remix",
| just "flask" or just [insert minimalist framework] I think
| they're either building something pretty trivial, or wasting
| a lot of time on rebuilding or integrating things you get for
| free with batteries included frameworks.
| kiwicopple wrote:
| (supabase CEO)
|
| We wouldn't be the best fit for all of these, but here are
| some:
|
| - Validations: handled already by Postgres and if you use
| JSONB you can use pg_jsonschema[0]
|
| - Translations: probably won't ever be part of our stack,
| but for multilingual FTS we offer the pgroonga extension[1]
|
| - Permissions: we offer AuthN (email & social logins, MFA,
| SSO) [2] and AuthZ with Postgres RLS[3]
|
| - Background jobs: pg_cron [4]
|
| - Caching: For images we have a smart cache [5]. We'll
| extend this to database queries over time
|
| - File uploading: supabase storage [6]
|
| [0] pg_jsonschema: https://supabase.com/blog/pg-jsonschema-
| a-postgres-extension...
|
| [1] pgroonga: https://pgroonga.github.io/
|
| [2] AuthN: https://supabase.com/docs/guides/auth/overview
|
| [3] AuthZ with Postgres RLS:
| https://supabase.com/docs/guides/auth/row-level-security
|
| [4] pg_cron:
| https://supabase.com/docs/guides/database/extensions/pgcron
|
| [5] smart image cache: https://supabase.com/blog/storage-
| image-resizing-smart-cdn#s...
|
| [6] supabase storage: https://supabase.com/storage
| jrvarela56 wrote:
| I mean, yeah you need more libraries, but I wouldn't list
| Formik/mobx/react-i18n/Sendgrid when talking at this level
| of abstraction.
| gardenhedge wrote:
| The post is literally about building an MVP. Remix isn't a
| minimalist framework - it's a full stack web framework.
| Rastonbury wrote:
| That stuff isn't "hard" per se, and some of that stuff
| isn't even needed for a MVP, they're good to haves or only
| really required when you've got 100s of users (product
| dependant of course). If the MVP doesn't get there either
| iterate product or bin it
| 0xblinq wrote:
| None of these are difficult per se. Multiple of them,
| working seamlessly together, having them tested,
| documented and battle tested is a bit more difficult.
|
| Then you think about all that time doing this could have
| been spent in actual business logic and it makes no sense
| to me anymore.
| cmbothwell wrote:
| This is a really nice stack and what I'm using together with
| a colleague right now.
|
| Do you use the serverless functions available with
| Vercel/Supabase? If so, I'm curious how you choose when to go
| with each provider.
| jrvarela56 wrote:
| I use vercel functions for this side-project bc they worked
| out of the box. Just least friction tbh not sure if
| optimal.
| turbobooster wrote:
| Wish I could afford vercel
| fullstackchris wrote:
| Super generous free similar product is netlify... you get
| 300 build minutes per month, I've never even gone above
| their free tier haha
| admn2 wrote:
| Unless something has changed, they explicitly disallow
| any website that facilitates for profit commerce. Granted
| I don't think they closely monitor it unless your
| bandwidth is over a certain threshold. However,
| Cloudflare Pages is free and unlimited FWIW but I doesn't
| seem as nice or fast as Vercel.
| bottlepalm wrote:
| Remember we're talking about MVP. Moving this stack to a
| VPS would only add a day.
| michaelteter wrote:
| > Con: does not move me in the direction of using Python more.
| Feel like this is going to be a must-have for AI-powered
| components.
|
| This is why too many companies build on Python... some thought
| that maybe someday they will need some AI something, and they
| hamstring themselves from the start with inferior tooling.
| halfmatthalfcat wrote:
| Mantine is such a good library, especially when compared to
| Material, Semantic, etc. I've used it with a couple projects
| and have been very impressed.
| foxandmouse wrote:
| I'm glad I came across your comment, I'm planning a 2-week
| project for learning purposes and I thought rails backend with
| react/ svelte would be the fastest way to prototype.
|
| My ruby/ rails experience is very limited compared to my JS
| experience; I really just started experimenting with rails. I'm
| blown away by the magic, JS frameworks feel like toys in
| comparison. I also like that Rails is omakase.
|
| Based on your experience, would you suggest trying rails or
| going the full JS stack route?
| weaksauce wrote:
| imo rails without react and leveraging hotwire is going to be
| the next big thing in web dev. react is a huge increase in
| complexity for not much appreciable gain. you are not
| facebook and don't have facebook's needs. rails is nimble by
| itself.
| JeremyNT wrote:
| I'm a fan of this too, and it honestly confuses me that
| people would do a Rails API with React _for a MVP_.
|
| If you're already doing the backend in rails, it's hardly
| any more work to just do hotwire with server side rendering
| at the same time, and you can switch to a SPA later (if you
| really do need to).
| 0xblinq wrote:
| Most people in this thread are not suggesting a stack for
| an mvp. They're just listing their favorite stacks,
| that's it.
|
| There's a comment of somebody saying that just Postgres
| and Go. How on earth is that a good stack for building an
| mvp?? You'll have to write a shit ton of code or glue
| together 10 thousand libraries.
| jrvarela56 wrote:
| I was faced with this decision a month ago and started
| building my models and views in Rails 7. Late night tinkering
| with views, then trying out ViewComponent I went 'dude wtf am
| I doing, these apps are so easy to build in React'... Next.js
| with Supabase has been a breeze. Setting up db with auth and
| getting realtime updates and object storage with minimal
| setup (TS fn calls) was mind-blowing.
|
| Caveats: setting up Supabase auth takes a bit of reading
| docs, using the js helpers correctly and configuring RLS, but
| after that it just works.
| insane_dreamer wrote:
| I'd stick with rails unless you have a complex front-end
| where UI responsiveness is of the essential (i.e., highly
| graphical-interactive). React is many levels up in terms of
| complexity.
| thomasqbrady wrote:
| What's RLS? Row Level Security?
| kiwicopple wrote:
| Correct. We suggest using Postgres Row Level Security if you
| use the Supabase APIs + Auth:
| https://supabase.com/docs/guides/auth/row-level-security
|
| You don't have to use RLS if you BYO middleware, but the RLS
| approach give you the option to do `frontent <-> backend` (vs
| `frontend <-> middleware <-> backend`)
| mlboss wrote:
| Django/Postgres/htmx(for interactivity) . I was able to release
| aipaintr.com in 3 weeks working 2-3 hours daily.
|
| All the new fangled frontend technologies make me dizzy :). On
| top of that this is my fist project in django.
|
| There is a nice django starter oss project called djangox which
| takes care most of the integration out of the box.
|
| For a new project the complexity should be on the marketing
| stack. Choosing a good tech stack is a distraction. Choose
| something that will allow you to create MVP fast and then start
| marketing.
| belthesar wrote:
| djangox definitely looks a bit less opinionated and lighter
| weight than what I normally use for a starter project, which is
| cookiecutter-django:
| https://github.com/cookiecutter/cookiecutter-django
|
| It seems to include most everything that djangox does, and a
| little bit more, and with cookiecutter's setup process, you can
| strip out much of what you don't want/need.
| rcarmo wrote:
| Django. It can run anywhere, including in lambdas, and I prefer
| having a solid piece of back-end that won't crumble when I start
| changing data models.
| dom96 wrote:
| Depends on the project.
|
| But in general:
|
| * Old School VPS or Cloudflare Workers (if the problem lends
| itself well to Workers)
|
| * Usually leaning towards sqlite instead of a hosted postgres (as
| that's often overkill)
|
| * Language: whatever fits the problem best. These days likely
| TypeScript as it's so versatile.
| throw1234651234 wrote:
| MVP should be built on things you will use later. Which is
| C#/Java/Python, React, and Postgres SQL unless your product has
| unique needs outside of the traditional space (it's a game, ML
| project, IoT project, mobile-only app, etc).
|
| Firebase is too expensive. Only use case if you have only front
| end devs.
|
| Dynomo/Mongo/Cosmos all do the same niche thing - you don't need
| a no-SQL db for most apps.
|
| 4. Apparently a lot of YCombinator companies still use Rails. I
| don't really understand why.
|
| edit: I didn't know about Supabase - thanks.
| v3ss0n wrote:
| Django/Rails make you a 10x developer. Thats why many who went
| for "Shiny New Things" are now coming back to Battle Tested
| frameworks , because nothing compares to those framework in
| terms of productivity in those shiny nodejs land of inventing
| wheel .
| deathemperor wrote:
| Nextjs deployed on Vercel Hasura with Postgres Apollo server
| deployed on Lambda using serverless framework.
| hooverd wrote:
| Django-Ninja but in Lambda with an RDS Postgres backend and a
| Vue/TS frontend. Why? Because it's what I know. It's on my agenda
| to learn more about Elixir. I think it really depends on what the
| MVP is for!
| leke wrote:
| Laravel + htmx + sqlite + Bootstrap
|
| I'm currently making something with these for the first time. I
| picked sqlite because it's convenient and seems to be supported
| on free hosting.
| mkl wrote:
| What free hosting supports SQLite?
| cloudking wrote:
| MySQL, PHP, HTML/CSS, JavaScript.
|
| If it's an MVP it doesn't need to be optimized with fancy
| frameworks until it has active users.
| alkonaut wrote:
| You mean specifically for products that involve the internet/web
| and is "full stack"? I'm not very familiar with the trends there
| but I do know I'd likely use a whole different toolset if I was
| only building a service without web frontend than if it had a web
| frontend. And whether or not it involves a database of some kind
| (and what kind) also heavily influences the choice of tools and
| platforms.
| aristus wrote:
| I've been writing Python for, gosh, almost 20 years now. I've
| used many frameworks but for an MVP I'd probably use good old
| web.py or Flask or similar.
|
| Over those years I've come to greatly appreciate the wisdom of
| Gall's Law. I always start with an absurdly simple system, make
| damned sure it works, and only then complicate it.
| qwerty456127 wrote:
| I would focus on functional languages. They don't change much nor
| often and guarantee (in 99% cases) everything is going to work
| reliably as soon as it builds successfully. The less people you
| have the more you need functional languages. Elm, Elixir, F#,
| Scala, Clojure, Kotlin etc.
| kentbrew wrote:
| Given that you are going to throw away every single bit of this
| code -- yes, you will, and yes, your investors should know about
| it in advance, and yes, you should set hard numbers for when it's
| going to happen -- you should build your MVP using whatever
| toolset will allow you to innovate the fastest while keeping the
| site up, safe, and secure.
|
| Agreeing with what has already been said about static HTML/CSS/JS
| on GitHub Pages with AWS buckets, but if Django or Rails works
| best for you, go with it.
|
| Unless this stack is works-best-for-you, beware launching on
| React, Typescript, Next.js, or Vercel. That's what you're going
| to use for the Real Version, when you have money to hire some
| Real Engineers who are okay with the level of complexity. Don't
| incur that tech debt before you absolutely must.
| mikewarot wrote:
| First I'd get it working on my Windows 10 PC, using Lazarus/Free
| Pascal.
|
| If it had to go on the web, then I'd try to output to
| WebAssembly.
| iambateman wrote:
| The best stack is the one you know.
|
| I guess I'm old school, but I built SimplifyRecipe.com in a few
| hours using Laravel. That's not to say that Laravel is better
| than anything else, but I'm extremely fluent with that ecosystem.
|
| I will say, I believe that Laravel or Ruby on Rails would be my
| favorite starting point for a solo development effort. I spent
| 1000+ hours working on JavaScript framework development and found
| it to be really cumbersome.
| 0xblinq wrote:
| I'm very fluent in JavaScript (I've been a js dev for 10 years)
| and don't have that much experience with Laravel yet. I totally
| agree with what you say.
|
| Even. It being fluent with pho and the ecosystem I find it
| incredibly more easy to learn and more productive. A lot less
| foot guns.
| brm wrote:
| Php/MySQL/html/css still the easiest simplest way to get anything
| out the front door
| debesyla wrote:
| Because in my experience MVP at first is a marketing test, not
| functionality - I need something to easily put text and images
| down :)
|
| ...So - anything. Simple WordPress page with some content builder
| would work.
|
| No need to invent functionality before testing out the need.
| robertwt7 wrote:
| I am sticking to Typescript nowadays, its so easy to share types
| between FE and BE, creates monorepo with many different packages.
|
| I am in fact building MVP right now with Nextjs and Nestjs, i've
| never felt more productive than this
| foobarbecue wrote:
| Django, using django templates and hand-written JS and CSS. No
| CSS or JS build steps -- that just makes things harder at the MVP
| stage, I have recently decided.
|
| I actually just built one. I tried a few other things first --
| started off in BlazeJS / NextJS, didn't like it, tried some other
| react & backend combinations and there were always obstacles. The
| kicker was that I wanted geodjango for geospatial support.
| ultrasounder wrote:
| Definitely old schools. I am building a MVP right now(kinda
| building my parachute while jumping off the plane)and I went with
| Django. And here is why. 1. Very vibrant community of devs and
| time-tested open-source libraries.If you want a multi-tenancy
| there is a library for that. IF you want stripe integration there
| is one for that. If you want "fully built out" services, then we
| have a plethora of free and paid templates. There are folks
| here(HN User rlawson)who have built many side projects using
| Django that they have monitized. if that monetization is your
| goal, then time is money and Django is your friend. 2. Very easy
| to deploy. This is a Major major requirement for someone like
| me(dabbling in webdev). Even after the demise of Heroku hobby
| dynos, there are things like Railway.app which lets you git
| deploy app, try it out and then scale it if you want. 3. Lastly,
| Javascript not necessary- I am a "hobby python dev". I don't have
| the inclination nor the time to learn yet another Javascript
| framework. I have an idea, know a bit of Python and I want to
| iterate it on my idea fast and get to the customer ASAP. Meaning,
| I can deploy a MVP without having to dabble with JS while jumping
| through all the different web pack configurations. A big win for
| me. So, "boring stack" definitely.
| cushychicken wrote:
| Did a big migration from Flask to Django for my main side
| project for all of these reasons earlier this year.
|
| I love Django. It's criminally underrated.
|
| Side project if anyone's interested in peeping it:
| https://www.fpgajobs.com
| ultrasounder wrote:
| Fellow EE here and love what you do! Loved your post on
| scraping.Btw, I thought you used Flask. Looks like I was
| wrong.
| cushychicken wrote:
| Thanks for the kind words. It's probably time for me to
| revise that a bit, or write another one. I've learned a lot
| more yet since I wrote that.
|
| I used to use Flask, but I changed over to Django at the
| end of 2022. Super happy I did. It wasn't painless, but the
| benefits have been totally worth it.
| agumonkey wrote:
| do you still use builtin views/templates ?
| ultrasounder wrote:
| Yes! Trying to keep it as simple as possible! Might try this
| whole HTML over the wire after I have made some dough. Not
| now tho. My customers don't give a damn about my stack
| [deleted]
| iwebdevfromhome wrote:
| one thing I'd like to see in Django is something similar to
| InertiaJS [1], just being able to use VueJS for the view layer
| is amazing and passing data from the backend to the frontend
| without having to build complex api systems is a godsend. Maybe
| I haven't done enough research but is there something similar
| in Django world ?
|
| [1] https://inertiajs.com/
| kolanos wrote:
| Still a bit raw on the edges, but IDOM [0] looks interesting
| and has a Django integration [1].
|
| [0]: https://idom-docs.herokuapp.com/docs/index.html [1]:
| https://github.com/idom-team/django-idom
| iwebdevfromhome wrote:
| interesting, is this something similar to htmx ?
| readonthegoapp wrote:
| Is there a multitenancy package?
|
| Is it this one?
|
| https://djangopackages.org/grids/g/multi-tenancy/
|
| I know there is a paid one.
| ultrasounder wrote:
| Yes this is the one. Or one could also use the
| https://django-tenant-schemas.readthedocs.io/en/latest/. I
| don't want to plug any paid options for obvious reasons but
| they are posted here regularly
| clint wrote:
| For context I'm someone who spent nearly 20 years doing almost
| exclusively python dev, attended the first DjangoCon in 2008,
| ran the Django community blog during its formation heyday back
| in the mid 2000's and built tons of Django modules, apps, sites
| etc, have commits on the Project from way-back, tech edited
| Django books, etc...
|
| Did rails for a short while in 2010-2012 and absolutely hated
| it then spent 2012-2020 doing mostly Python/Flask dev for huge
| fintech companies on AWS.
|
| I now use Javascript/React/Nextjs on Firebase/Google Cloud. So
| much less hassle, tons more libraries and what seems like an
| exponentially larger ecosystem. There's still weird shit with
| transpiling typescript to javascript etc... but overall I enjoy
| JS dev much more these days.
| squidsoup wrote:
| As a long time python dev, I'm now not certain why I would
| use python for a web app, over typescript on Next, other than
| familiarity. Sharing types between the server and client, and
| only having to manage _one_ software ecosystem is great.
| speakfreely wrote:
| What to you use for ORM/database migrations with Next.js
| apps?
| davepeck wrote:
| Some potential reasons:
|
| 1. The data layer, if you want a high-quality ORM and
| migrations
|
| SQLAlchemy + Alembic (or Django ORM + its built-in
| migrations) are battle-tested systems that I trust will
| scale to large teams and _not break my data_.
|
| If you're more of the persuasion to write raw SQL, or to
| just use a SQL query builder, Python is less of a draw
| these days (although SQLAlchemy's query builder is quite
| nice and can be used independent of its ORM).
|
| 2. Ties to the data science + machine learning universe
|
| If your back-end intersects with these in ways that are not
| cleanly separable into services, Python might be a good (or
| the only) option. Even if you _can_ cleanly separate, you
| 're effectively committed to managing Python on the back-
| end.
|
| 3. Stability
|
| For good and ill, the JavaScript ecosystem churns far more
| rapidly.
|
| 4. Familiarity
|
| To your point: there's nothing wrong about optimizing for
| creature comforts and/or velocity from just having done it
| before and fired the foot-guns.
|
| ---
|
| I agree that using a single language provides an advantage
| at the API boundary. Curiously, my experience is that most
| modern javascript frameworks (like NextJS) don't have a lot
| to say about how to structure this in practice. Maybe
| that's fine, but I'd love to see some opinions emerge in
| the ecosystem.
|
| Amongst other things, I typically want to:
|
| - Share types (typescript `interface`s, etc.) between the
| front-end and back-end (while avoiding accidentally
| bundling back-end code into the front)
|
| - Have run-time types (via `zod`, `io-ts`, whatever) for
| (at minimum) API request structures so I can validate my
| inputs
|
| - Have a story about how API validation failures are
| shipped back to the client (and how the client exposes them
| to the users, e.g. error messages when filling out form
| fields)
|
| - Differentiate between API types and my underlying data
| model (the `User` in my database is somewhat to very
| different from the `APIUser` I ship to my client)
|
| In the python universe, Django, Flask, and FastAPI all have
| well developed opinions about run-time types, validation
| failures, and API types vs. data models.
| vonseel wrote:
| On 1 - I've worked at startups using Django ORM and
| banking companies using MSSQL stored procs. I don't
| understand why anyone would ever go the stored proc/raw
| SQL way unless they absolutely needed the performance.
| And if you do need the performance, you can always dip
| down to that level from whatever ORM you are using.
|
| Most of the queries I've done using Django can be
| optimized at the application code level to be fast and
| efficient without even touching SQL. There were a few
| instances at the two Django shops I've worked where we
| optimized one or two queries by writing raw SQL, but the
| number of times I've seen that in a codebase can be
| counted on one hand.
|
| The SQL/stored proc method, on the other hand, doesn't
| come with any way to do migrations or version your
| database by default (AFAIK). So now you have to write
| migration code and come up with some kind of versioning
| system by hand.
|
| Wish I had more experience with SQLAlchemy/Alembic. I've
| tried using it on little things here and there but since
| I've always known Django, that's what I usually go with.
| alexalx666 wrote:
| Be aware that firebase or aws are only good until you have
| actual traffic. So in many cases you just loose time you
| spent understanding their managed infra. I would advice to go
| with Linode. As a bonus you get to lean new techs that are
| not tied to crazy managed pricing :)
| christiangenco wrote:
| I had a similar journey but with Rails and ended up in a
| similar place.
|
| React+Nextjs on Firebase makes the deployment and scaling
| steps _so much easier_ than on Rails. I 'm very conscious of
| the platform risk of depending so much on Firebase but gosh
| darn it they've spoiled me.
| FlyingSnake wrote:
| It's funny that only in our industry "time tested"/"battle
| tested" is called old school and frowned upon. No wonder we see
| software bloat everywhere.
| brookst wrote:
| Eh, I think experimental physicists and medical imaging also
| lean towards newer tech.
| randomh3r0 wrote:
| Eh.. you'd be surprised. Medical Imaging isn't as radical
| as you may think it is (I spent 7 years doing projects for
| the exploitation of medical images).
| incompleteCode wrote:
| Anecdotal, but a co-worker's parent works at NHIS and
| I've heard they've adopted Kubernetes.
| brookst wrote:
| I've had the pleasure of annual echo cardiograms my whole
| life, and moved around a lot, and at least my experience
| has been visible hardware/software/imagine improvements
| almost annually.
|
| In any event I wasn't saying all medical imaging is state
| of the art, I was saying it is another field where people
| prefer newer tech.
| randomh3r0 wrote:
| Absolutely fair. The vendors have gotten much much better
| tech "in the room" as it were - CT's are lightning fast
| anymore, US is clearer and can do more on-the-fly
| analysis than ever before (e.g. highlighting bloodflow
| dynamically and capturing tons of data in microseconds),
| etc. Every modality has grown tremendously so my comment
| wasn't nearly fair enough in acknowledging that.
|
| Downstream is getting better with items such as AI
| advancements and more sophisticated mechanisms to
| transfer data between systems both on-prem and cloud-
| based, however utilization of all of this tend to be
| stifled a ton by the standard issue of tech moving faster
| than policy. My frustration/disgruntlement is due to this
| issue more than anything.
|
| Thanks for the insight and the reminder that my bubble of
| experience isn't the world - seriously.
| marcosdumay wrote:
| No area of health work tends towards new tech. It's
| disallowed by regulation.
| humans2 wrote:
| [dead]
| nicbou wrote:
| Agreed, although I'd really like to throw in type safety,
| because the lack of it made my life needlessly complicated. Is
| this feasible with Python?
| gmassman wrote:
| Type hints in Python are nice, by pale in comparison to truly
| typed languages. If you want to feel like your language's
| type system significantly improves your development
| experience and the safety of your code, don't pick Python.
| mattficke wrote:
| It's not enforced at runtime, but otherwise I feel like
| typing is in a pretty good place in Python right now. If
| you're diligent about using Pyright or MyPy as linters it
| makes life a lot easier.
| bm-rf wrote:
| Type hints in python also work great with vscode (and
| probably other IDEs) as it can offer better autocomplete
| suggestions for things like function parameters.
| hooverd wrote:
| The one thing that Django is missing is the ability to attach a
| User object to a session without a full-fledged RDBMS. I wish
| it was structured like the Session object which you can in your
| own backends for.
| jsmeaton wrote:
| This is unlikely to ever happen though since so much is tied
| to it like the permissions system and the admin. The ORM
| itself is central. I wouldn't use Django unless your project
| depends on an RDBMS.
| noveltyaccount wrote:
| IMO for early stage startups, proven tech is almost always a
| better bet than the hot new thing. Your goal is to capture
| market share quickly, not wrangle beta tech into place.
| intelVISA wrote:
| Fully custom runs anywhere stack, hand written OS, orchestrator,
| VMM and TLS*
|
| *bearSSL powered because I can't into curves myself :/ as the
| only external dep
|
| if state is needed I lean on DuckDb but eventually a more
| optimized in-memory columnar data structure will be devised.
|
| Mostly because I found all the other options in this space to be
| lacking for performance-oriented low latency services.
| f6v wrote:
| The one I'm most comfortable and experienced with. Because I
| think MVP is about getting the product out of the door above all.
| vipull wrote:
| FLask would be myy pick!
|
| I have worked with it in the past, and having familiarity for the
| MVP trumps all, for me. As I can rely on it to provide me with a
| solid backend without having to worry about unexpected..
| traverseda wrote:
| Depends on exactly what I'm making, the answer is probably
| different if I'm making like a chat app or something more data
| centric.
|
| For something really minimal, an internal tool, I'd probably use
| grist. Grist is a "no code" spreadsheet program that is open
| source and works on a relational database. I just threw together
| an inventory management system for my weekly dnd group in a few
| minutes, and I've shared it with the group. I find the relational
| mindset grist uses a lot easier to reason about than traditional
| spreadsheets.
|
| The next level up would be django with htmx. Very minimal
| javascript, I might embed a javascript "applet" like a map into
| it if needed. This covers 99% of data driven apps.
|
| If I wanted to build something like say discord I'd probably use
| a pretty similar stack for the MVP, but with server-sent-events
| (htmx with server sent events is nice) and web components for
| more complicated interactions. That's probably why I'm not in
| charge for building complicated single page webapps with a lot of
| interdependent state though. I maintain this approach should work
| but haven't had a real chance to test it in the wild.
|
| If I'm writing CAD software I'm probably going with
| QT/python/(numpy/jax/compute-shaders/sympy/etc). Python might not
| be the fastest, but when you're accelerating it with one of those
| machine learning libraries it can be really powerful. I've
| actually been working on something CAD-ish using that stack here:
| https://github.com/traverseda/PySdfScad
|
| That's probably roughly the same stack I'd use for things like
| computer vision, machine learning, etc. Ironically anything where
| performance is important I'd probably choose python over a
| compiled language.
|
| Mind you the QT python documentation is really not great, for a
| really minimal MVP I might swap qt out for pyimgui which is
| amazing for rapid prototyping but is going to be a real pain to
| do things like syntax highlight a text editor or embed HTML
| content.
|
| Embedded electronics? Probably micropython on an ESP32 for an
| MVP. A REPL on your microcontroller is really nice. Robotics I'd
| probably use buildroot to build a custom linux distro. ROS is
| pretty heavy and I find it gets in the way a lot, but if you need
| ROS stuff obviously use ROS.
|
| I don't have much experience with mobile development, so I'd
| probably end up using QT with python and pyqtdeploy, but that's
| not an approach I'd recommend anyone else follow. I'm keeping an
| eye on Tauri in that space, although I really wish they made it
| easier to bundle in things that aren't single page javascript web
| apps (like a python application).
|
| So yeah, mostly I'd use python. Master of some trades, jack of a
| bunch of others, it's flexible and powerful enough that I feel
| happy to have specialized in it, even if deploying apps to end
| users can be finicky and annoying. I'd avoid the javascript
| ecosystem as much as possible, and where I'd have to use
| javascript I'd prefer to make self-contained web components.
| revicon wrote:
| Front end: Is SEO relevant? YES: AWS Lambda generating server
| rendered HTML behind API Gateway. NO: Vanilla React.JS app hosted
| on S3
|
| Back End: AWS Lambda behind API Gateway
|
| Database: AWS DynamoDB
|
| This stack will reduce down to _zero_ usage costs when there is
| no traffic and will scale up to much more than I will possibly
| need for anything resembling an MVP with no interference required
| by me.
| dtx1 wrote:
| Could you elaborate (or link to a framework) for doing the
| server generated HTML on Lambda?
| revicon wrote:
| I mean I'm literally building an AWS lambda function that
| outputs HTML when it's called via API Gateway. So someone
| hits https://mydomain.com/mycoolpage, then the MyCoolPage AWS
| Lambda function is executed, does database queries or reaches
| out to other lambda functions I've built as microservices and
| then outputs <html>whatever</html>.
|
| If you're interested, I use https://middy.js.org/ as a
| middleware engine for my AWS lambda functions which I find
| helpful.
|
| I use the open sourced serverless framework for doing deploys
| https://www.serverless.com/ though I'm probably going to move
| to using AWS SAM in the future.
| dimgl wrote:
| tRPC is incredible. I can imagine most businesses doing just fine
| with a single VPS on Vercel with a static React frontend and a
| tRPC backend. The iteration time is insane.
| dimmke wrote:
| SvelteKit + Supabase.
|
| It's the opposite of what a lot of people recommend. It's not
| battle tested. Both of these technologies are still maturing BUT:
|
| I can write everything in JS/TS, I don't have to get good at Ruby
| PHP or Python
|
| Postgres is a great skill to learn.
|
| Supabase is portable and can be self hosted, and its JS client is
| easy to use for DB manipulation and stuff like object storage.
|
| For me, building a true full stack web app (not a todo list
| tutorial but something with real custom features) was going to be
| a learning process because I've been so heavily front end
| focused. So I decided to try to learn with the most modern tools
| available. It's mostly worked out. I've had to ask for help on
| Discord a lot, especially with Supabase.
|
| I have this idea for a blog post called "it's just a CRUD app"
| that kind of challenges this idea that CRUD apps are brain dead
| simple. When you look at the myriad of options for building and
| deploying one. We're talking like 50+ frameworks. Methodologies
| like dependency injection, micro service and monolith patterns.
| Yeah maybe it's simple if you have been doing it for 15+ years
| and are comfortable with your stack but if you're newer to the
| game, there's a lot of complexity at play and the best choices
| for your situation are not obvious. Before moving to Supabase I
| was using NestJS because I was convinced I needed this framework
| with guard rails, but I hated it. So moving off that caused a lot
| of churn.
|
| Edit: I also wanted to mention that the biggest split amongst all
| these recommendations IMO is how the backend and frontend
| interact with each other. Some of these frameworks will render
| frontend views for you. Then you're dealing with a very classic
| web app. Then you hear other people in this thread talking about
| HTTP handlers, and it's clear they're talking about the backend
| existing as a REST API, which IMO is a bad pattern to use for
| your own app. REST APIs should be used for exposing your service
| to third parties.
|
| But there's a third way, that's becoming popular amongst the
| "bleeding edge" with things like Next.js and SvelteKit that have
| a "backend for frontend" where they have to run a node/deno based
| server anyways to do on demand SSR and hydrate. Having a separate
| backend, especially a separate backend that is just a REST API
| leads to a ton of redundant code and confusion.
|
| So instead with ORMs like Prisma, people setting a persistent DB
| connection on this backend server and accessing/manipulating the
| DB directly with some kind of client. I think this approach came
| to prominence alongside the rise of GraphQL. That's basically the
| way Supabase works - they have a JS client and you interact with
| it in a similar way you would Prisma or TypeORM. They even have
| an article about how their client can be used in a similar enough
| way to GraphQL that it's not worth using GraphQL instead.
|
| Instead of traditional controllers where you would stash a lot of
| business logic (including authorization), the idea is you
| leverage PostgreSQL's advanced features to help with that. I'm
| not a huge fan of this for multiple reasons. So you kind of have
| to make your own decisions on how much abstraction you're going
| to put on top of their client.
| imnnos wrote:
| So I'm fairly new to the world of full stack web development.
| I've been trying to make an MVP using SvelteKit and Firebase,
| but what I'm running into is that they both kind of try and
| avoid a separate backend in different ways that seem to
| sometimes conflict with each other.
|
| For instance, Firebase is meant to connect on the client so you
| don't need the backend database connection, but then you can't
| use SvelteKit's SSR. Does Supabase work similarly in this
| aspect? What do you do in this situation?
| patrickmay wrote:
| This is Hacker News, so why am I the first to suggest Common Lisp
| (SBCL) and Hunchentoot with PostgreSQL on the server? I'd default
| to Vue for the frontend.
| cdelsolar wrote:
| I've gotten fast enough with Go + Twirp/proto for the API.
| sqlc+pgx for the database interface. (i.e. generate as much code
| as possible). I have a couple of functions/middlewares I can pull
| in for user auth. I don't think this is that much slower than
| Django if at all.
| cultofmetatron wrote:
| elixir/phoenix is the best platform for knocking out an MVP
| today. Its batteries included and has a frontend system called
| liveview that lets you write most of your frontend using elixir
| too. You get built in pubsub and websockets which are important
| for any new kind of software product. Users demand more
| interactivity and phoenix lets you do it and scale from day 1.
| Ecto is easily the best sql database library I've ever worked
| with. Its comparable to linq only it is uses elixir macros so its
| just a library.
|
| 1. you get a lot of out of the box rails like glue jsut like
| rails or django but the runtime perf is way faster. you can get
| away without even using caching in prod for awhile
|
| 2. supabase is written in elixir
|
| 3. lambda could functiosn have their place but loc you in to a
| cloud provider. I can move my elixir mvps accross providers with
| no issue and I won't get any surprise bills.
| tluyben2 wrote:
| I love elixir/phoenix and wish I could use them in prod for my
| job, but...
|
| > pubsub and websockets which are important for any new kind of
| software product
|
| ... not really. By far most people (probably by a huge margin)
| are doing fine building 1000s of new products per week without
| either those things.
|
| Further I think you are right.
| linuxftw wrote:
| Holy smokes! I had no idea this project existed, and it just
| solves so many issues out of the box.
|
| I'm a backend/infra developer, and I had been dreading having
| to learn a new front end framework because the work flows just
| look hideous. This looks like I can sidestep most of that
| problem entirely.
| cultofmetatron wrote:
| phoenix has been the inspiration for a lot of stuff comming
| out of the other frameworks.
|
| phoneix channels -> django channels and actvecable but
| phoenix's version is much more powerful
|
| liveview -> livewire, hotwire. both are copies of liveview
| but neither of them are as powerful since only liveview can
| spinup a persistent thread PER user allowing active stateful
| sessions that can push and recieve events from the client.
| omnimus wrote:
| Not claiming LiveView is not most powerful (probably is
| because erlang is most suited to this). But saying that
| Livewire or Hotwire are copies is not fair at all. I am not
| sure why they are named in so similar way but they are all
| green field projects.
|
| Livewire has started at pretty much same time as LiveView
| and AFAIK both projects influenced each other over the
| years. Both authors are in contact and the frameworks are
| quite a bit different because Livewire (in PHP) does
| everything over http so it has to employ different tactics
| than LiveView that can run over websockets.
|
| Hotwire on the other hand is from Basecamp who have been
| using this approach forever. They just packaged their
| experience into a framework they released. Theoretically
| hotwire is the oldest of the three.
|
| I am saying this because i don't think you need to use
| LiveView. All of them are super productive and are used for
| many real projects. They are just a bit different and
| better at different things.
| ch4s3 wrote:
| Phoenix is super pleasant to work with, very few surprises.
| chadmckenna wrote:
| I'd go full stack Rails with Turbo and Postgres DB. As things
| grow, you can easily migrate your Rails app towards a JSON API
| layer and create new clients to interact with it either with your
| favorite JS framework or mobile app. I just love how quickly you
| can churn out new features in Rails -- or how easy it is to
| implement things like authentication or an admin panel by simply
| adding a gem.
| 30minAdayHN wrote:
| I still use my Rails + Postgres + Heroku with various gems like
| omni-auth, pagination etc. I have created a shell app that is a
| blank website with login mechanism and basic data. Anytime I have
| an idea, I can spin up a site within couple of days.
|
| I was tempted about upgrading by default stack, but after lot of
| wise advise here, I think it's better to stay in a stack where
| velocity will be high rather than wasting time in learning new
| things (unless that is the goal)
| nodemaker wrote:
| My sweet spot is
|
| 1.Flask with Postgres for API. 2. C++ with Pybind11 for core
| performance engine. 3.Whole stack running on a single cloud
| instance with docker compose. 4.Next.js, Typescript, Tailwind for
| frontend. 5.Github Actions for CI/CD and deployment to cloud.
| blablabla123 wrote:
| Definitely 1., velocity is kind of predictable, it's cheap and
| easier when working with more people. I like also more up-to-date
| stacks but collaboration is more tricky I think
| maleero wrote:
| Python, Django, HTMX, AWS all the way, baby.
| eandre wrote:
| This is one of the core use cases where Encore [1] really shines.
| It helps you get up and running really quickly by natively
| supporting common cloud infrastructure components (databases,
| Pub/Sub, caching, cron jobs, secrets management, etc), and a
| simple low-boilerplate way of defining APIs.
|
| It automatically provides API docs, architecture diagrams, and
| infrastructure provisioning, based on static analysis of your
| code base.
|
| Disclaimer: I'm one of the founders.
|
| [1] https://encore.dev
| knapcio wrote:
| React + Apollo GraphQL (on Node) + Mongodb (with Mongoose,
| possibly hosted on Atlas)
|
| The reason is simple: I'm most comfortable and proficient with
| this stack and it's scalable enough to run a mid-sized app.
| Moreover it's very easy to share the code base between web app
| and mobile app based on expo (React native) if needed.
| quicksnap wrote:
| About a year ago I took off maybe 5 months to create a ephemeral
| voice messaging mobile app (Android + iOS)
|
| Stack:
|
| - React Native + Expo - Typescript - Supabase - Vercel - Some
| Vercel/nextJS-ish lamda functions so I could avoid AWS (Supabase
| didn't have that kind of offering yet)
|
| For me, it was _very_ pleasant to work in. I was able to ship
| features via OTA updates from idea to live in literally minutes..
| sometimes even under a minute.
|
| Loved working with Supabase.
| speakfreely wrote:
| How did you define your models and manage database migrations
| with Supabase?
| quicksnap wrote:
| After things were live, my migrations would be backward
| compatible. It's also possible to organize your tables where
| most of your data is in private schemas, and public views
| serve as your apis and versioning. Anything in a public view
| must be treated as a long-lived API until clients can be
| phased out.
|
| My userbase was in the dozens at most, so pushing out a
| version OTA usually was effective to get things moving along.
|
| Worst case, I had some code to check if the client version
| was too old and would shut it down until they updated.
|
| As per models, what kind of details are you asking?
| andrewmunsell wrote:
| Personally, I've found node-pg-migrate works well for a Node
| stack and Postgres migrations in Supabase. Then, I primarily
| interact with the database using the Supabase GraphQL API +
| RLS.
| Taek wrote:
| Plain js on the frontend. Complex logic handled in rust-wasm.
| Backed handled in Rust using the Actix Web http server, using
| websockets, proxied through a very basic nginx instance with TLS.
|
| My own servers for the entire cloud, maybe with CloudFlare as a
| CDN.
|
| Avoid anything else as much as possible. If you need AI/ML,
| you're going to have to pull in some difficult extra stuff, so
| make sure the value is there.
|
| Owing both to the unreasonableness of the modern javascript stack
| (node/eslint/jest/react/typescript/webpack) and also to the
| considerable improvement of vanilla js over the past 10 years, I
| really don't feel like all the extra frameworks are worth the
| overhead and dependency risk on the frontend. Vanilla js is
| really good these days! And when you need a boost, rust wasm is
| also really good.
|
| I've found that it's a lot faster - and also a lot safer! - to
| build in vanilla js than I ever would have expected. Typescript
| still adds value, but imo not nearly enough value to earn a place
| in the stack.
| crummy wrote:
| What's the advantage of doing complex logic in rust-wasm? I
| assume you mean in the frontend?
| rasulkireev wrote:
| Django, SQLite, StimulusJS, TailwindCSS, DigitalOcean Droplet,
| MailGun
| KronisLV wrote:
| Hosting: probably one of the more affordable VPS providers out
| there, like Contabo, Hetzner, or in my case Time4VPS. Homelab
| servers (just boxes with Debian/Ubuntu) for dev/testing
| environments at first. Probably some popular OS like Ubuntu for
| the remote servers as well, just because of how easy such a setup
| is to get from any provider.
|
| Runtimes: OCI containers with Docker, there are other options out
| there as well, but this one is stable and boring, plus makes
| deployments easy. Probably at least something like Docker Compose
| or maybe Docker Swarm (more or less uses the same format) to
| orchestrate stuff across multiple nodes and take care of
| networking, if needed. Maybe Portainer for easier management. Can
| later move to Nomad or Kubernetes if needed, but the previous
| options are good enough.
|
| Databases: probably MariaDB/PostgreSQL for relational data, if
| needed then MongoDB as a document store, MinIO (S3 compatible)
| for any larger binary blobs, Redis for key-value storage and
| RabbitMQ for queues. Admittedly, in most cases you won't need
| that much more than just a single relational DB instance, unless
| you have particular workloads to deal with. Honestly, even SQLite
| can be a good starting point for a single node deployment.
|
| Back end: honestly, any of the most popular languages out there.
| Java (either Dropwizard or Spring Boot) or .NET (ASP.NET) for
| good performance and rich ecosystems, Go for small statically
| linked executables, Python for packages to do basically anything
| (most likely Flask/Django in webdev), Ruby for particular CRUD
| setups (with Rails), Node (most likely with Express.js) for
| getting up and running relatively quickly. Personally, I'd opt
| for static type systems when not in too much of a hurry, but also
| recognize the benefits of any of the options listen. Frankly,
| they're all good enough, so just pick whatever feels suitable for
| the problems you want to solve. Even PHP with Laravel is viable
| nowadays.
|
| API design: probably something RESTful, though some like GraphQL
| (personally, I think that it brings a certain amount of
| complexity with it), in rare cases would also go for something
| like gRPC or also WebSocket stuff, though again it depends on
| what you're building.
|
| Front end, server side rendering: if you decide not to make a
| RESTful API but are okay with server side rendering (certain
| Django, Rails, Laravel setups, for example), then you won't have
| to think about this too much. In those cases, I'd just throw in
| something like Bootstrap and maybe something to make dealing with
| JS easier.
|
| Front end, SPA: However if you're building a SPA (which is great
| because you can swap out front ends or use it for other stuff,
| not just the current UI) then I'd recommend you look in the
| direction of Vue 3 + a component framework/library like PrimeVue.
| Angular does TypeScript really well but is cumbersome to work
| with, React seems to get more and more complex with every
| release, whereas Vue does everything from hooks to recommended
| state management solutions (like Pinia) well and without too much
| accidental complexity. I'd pick the component framework/library
| because making your own is sometimes a waste of time. I'd
| consider TailwindCSS, but not always.
|
| Web servers: personally I'd go with Apache for my own reasons
| (modules for most stuff), but Caddy is also excellent. Nginx is
| also good, but doesn't do ACME certs out of the box, although
| setting up certbot isn't too hard. I've written on my blog about
| using Apache, actually: https://blog.kronis.dev/tutorials/how-
| and-why-to-use-apache-... and about Nginx as a reverse proxy.
|
| Day 2 concerns: I'd also look into Matomo analytics if the MVP
| gets popular, as well as Zabbix for server monitoring, Uptime
| Kuma for uptime monitoring, maybe way later something like
| Graylog for log shipping and Apache Skywalking for APM/tracing.
| For managing nodes, Ansible can be a good bet later.
|
| So it might look like: Ubuntu + Docker + MariaDB + Ruby + Rails.
|
| It might also look like: Ubuntu + Docker + PostgreSQL + Node +
| Express.js + REST + Vue + PrimeVue.
|
| Or any other number of combinations. It's hard to go completely
| wrong nowadays. Cloud options are also nice, but personally I
| like being able to run basically the same thing both locally and
| on a server somewhere. Actually, I had a somewhat related blog
| post about this, "How boring or novel should your technology
| choices be", too: https://blog.kronis.dev/articles/how-boring-or-
| novel-should-...
| mythrwy wrote:
| Django, and possibly DRF with Vue if more dynamism was needed.
| keraf wrote:
| I'd probably go with NextJS and Pocketbase[0]. I like to start
| with everything on a single instance/machine, cheaper and less
| overhead, allows me to focus more on building things rather than
| ops.
|
| [0] https://pocketbase.io/
| yieldcrv wrote:
| Next.js, React, Netlify, Ipfs+Filecoin
|
| Not sure about where I would store relational data, I typically
| design systems to not need it, its just a system design problem
| fzeindl wrote:
| - Next.js frontend/backend, edgedb on top of postgresql, Linode
| server behind cloudflare. No Kubernetes.
|
| Or, if you want to be more classical:
|
| - kotlin backend using dropwizard, jdbi ORM connecting to
| postgresql. No kubernetes.
|
| Or, if you want "plug and play" as backend:
|
| - next.js, supported by postgREST. No kubernetes.
|
| Or, if you want something exotic:
|
| - elixir/erlang/phoenix as frontend and backend, no kubernetes.
|
| I think the future is probably
|
| - some frontend, edgedb, no kubernetes
| uoaei wrote:
| Good timing: a lot of top-level comments here mention Rails on
| Docker, then this post rockets to the top of the front page:
| https://news.ycombinator.com/item?id=34533930
| rajatsx wrote:
| These days I prefer Next.js + MongoDB for full stack apps.
| Pushing changes to a repo and have it deploy automatically feels
| like a super power.
|
| I have a moderately complex project, which is built using Next.js
| but it uses Yarn workspaces (for code sharing) and Docker (for
| deployment) but I waste a lot of time putting out fires w.r.t
| this setup than actually building features. I am thinking about
| doing away with Docker and Yarn 2 to keep the setup simple.
| theshrike79 wrote:
| AWS Lambda + C# or Golang with S3/Redis/DynamoDB backend. Maybe
| Aurora Postgres if you need complicated queries.
|
| It's boring but it works. It also scales as far as your wallet
| can handle.
| dangerboysteve wrote:
| NextJS/Supabase/TypeScript/Tailwind/React Native
| alexbezhan wrote:
| Ubuntu + Node.js + HTMX + SQLITE
| recursivedoubts wrote:
| rails, because it has so much baked into it
|
| htmx & hyperscript because I made them
| bitwize wrote:
| CL with Hunchentoot and PostgreSQL on the back end, probably.
| epolanski wrote:
| The stack on which I feel more comfortable right now:
|
| TypeScript on both sides with fp-ts[1], effect-ts[2], Postgres or
| any random document database with low friction, a random view
| library that has the best support for jsx and both client/server
| side rendering (not react).
|
| Any other stack would require me to learn new stuff and
| eventually slow me down.
| adius wrote:
| Frontend: Elm + Tailwind, Backend: Haskell (or some instant API
| Generator like Postgrest / Airsequel), Database: SQLite,
| Automation: n8n / Pipedream / Zapier / ...
|
| The strong typing of purely functional languages makes
| refactoring a breeze and let's you quickly iterate and move from
| prototype to production.
| nyxcharon wrote:
| After working with the PETAL (Phoenix, Elixir, TailwindCSS,
| Alpine.Js, Liveview) stack at $JOB for a while now, I have to say
| I've never been more productive.
|
| Early on I would still have to lean on Alpine heavily for various
| JS interactions but with all the features Liveview has been
| adding and improving on (Hello JS module!) I find myself needing
| it less and less. Liveview really has been a game changer for me.
| Tailwind has more or less fixed most of my frustrations with CSS
| and has worked itself nicely into the company design system
| resulting in nice re-usable components that can be easily
| customized for those one-offs. Elixir is a nice language to use
| and I find myself missing features of it when working with other
| languages. Phoenix is well structured for projects and the newer
| generators solve a lot of common issues/features in projects like
| user auth in a reasonable way.
|
| Depending on the needs of the app I'd look into deploying to
| Fly.io otherwise I've been using Kubernetes with little issue.
| I've toyed with Nomad for orchestration but haven't used it
| enough to give an opinion. I do wander if it's a nice middle
| ground for those who don't need the full suite of what K8s
| offers.
| davehcker wrote:
| I second this. I would say that I am pretty advanced with
| Python (and Django) and same with JavaScript (Vue and Nuxt) and
| have written applications that got used by multiple users. I
| saw a sharp rise in my productivity when I knew enough about
| the frameworks. But Elixir + PhoenixLiveView + Tailwind has
| been life changing.
|
| I learned Elixir for the sake of the joy of learning a new
| programming language and I kept playing with it for few random
| days over 5-6 months. Finally, I took the leap of faith and for
| our startup I started the switch to Elixir + LiveView with
| minimal JavaScript hooks and I feel a weird bliss that we are
| two engineer FTEs and I can add features on a daily basis. Why
| that's the case, I still haven't ruminated myself, but my guess
| is 1. I have gotten older, 2. Elixir is beautiful and
| productive by design-- pattern matching, everything is a
| process (so the dimensionality of time is not an issue at all)
| and the code is kind of a right balance of simplicity and
| complexity, and in my opinionated view, there is "one" right
| way of doing things. 3. Standard tooling (mix, ExUnit). They
| have enabled us to write really maintainable code and for our
| next hires, we are willing to pay for them to learn Elixir than
| switching to other languages. Of course this is only for true
| for our web app which is actually a weird beast that interfaces
| farms, sensors, algorithms, and humans.
| kodah wrote:
| Awesome experience write up.
|
| Question for you and OP, do you find that using languages
| like Elixir makes it so you have to look for a _certain kind
| of dev_ given that Elixir is a pretty niche community or are
| folks with no experience able to adapt with relative ease?
| nelsonic wrote:
| Not one of the OPs but can happily echo their
| experience/praise for PETAL and think I can answer your dev
| search question:
|
| Anyone with a can-do attitude can learn Elixir. People with
| a "no thank you, I already know XYZ" mindset you _really_
| don't want on your team.
|
| Almost 20 years ago @pg wrote the "Python Paradox" post:
| www.paulgraham.com/pypar.html
|
| The same holds true for Elixir (and Rust) these days. The
| people you want to hire are those who learn new
| skills/languages proactively.
|
| However I can confidently say, from experience of having
| hired several Python devs/data scientists with zero Elixir
| experience, that smart+motivated people can learn Elixir in
| a couple of days and be productive within a week. See:
| https://www.verytechnology.com/iot-insights/elixir-for-
| pytho...
| kodah wrote:
| That nailed what I wanted to know. Thanks!
| john_the_writer wrote:
| I'd argue the other way. Yes anyone with a can-do can
| learn Elixir. But there's a difference between learn and
| LEARN..
|
| I work with a pile of rails devs writing code in elixir.
| In that I mean you can feel the rails in their code. It
| "tastes" like rails. A few python devs also write python
| with elixir syntax.
|
| Finding people who know the language is hard. Finding
| people who are willing to risk their time on the language
| is also hard.
|
| By risk. If I spend 2 years writing Elixir and then go
| looking for a job I'm looking at getting a job with a
| language that's not popular. So my pool of place that
| will even look at me is smaller. Hiring managers/gate
| keepers might not see..
|
| After 12 years of c++ I got a job where I needed to code
| in Delphi-Script for a year. When I told recruiters what
| I'd been doing I got "Oh.... Okay um... We'll call you."
|
| I switched to rails for 6 months (same job) and
| recruiters were calling me non-stop. Working in low
| popularity langs limits my options. (even if they are
| great langs)
|
| I'd say picking a language that's not yet popular limits
| your pool not just to the can-do's, but also to the can
| get my next job with this on my CV.
| davehcker wrote:
| I didn't want to confess, but yes you're right. Elixir (or
| the willingness to learn Elixir) is a great filter for me
| to find the right people. Again, this is my purely
| subjective opinion and might as well be true for other
| languages as well.
| nyxcharon wrote:
| I'll more or less echo what nelsonic said.
|
| No one where I work has come in with Elixir experience. We
| look for people that are motivated to learn. Elixir has
| been one of the easier languages in my career to learn, and
| I think others that I work with would agree with that.
| eddsh1994 wrote:
| Moving from Python/JS -> Elixir at a startup seems very high
| risk, have the rewards been worth it? I can imagine issues
| with hiring, unknown unknowns, and less libraries/support in
| general.
| davehcker wrote:
| I know-- I was scared like hell. But after the first week
| and multiple staging releases in less than 10 days, I was
| on top of it. Yes, hiring is real challenge and am facing
| it already. However, if I, even as a startup, reach the
| salary threshold, then hiring is not a problem. I'd say
| I've yet not found a case where I couldn't find a library
| for my use case.
| arnonejoe wrote:
| I'll second this. Alpine.js is so nice.
| afhammad wrote:
| Adding my vote here. Throughout my career I've gone the C#.NET
| -> RoR -> Clojure -> Elixir/Phoenix route. After spending a
| year with Elixir, iterating rapidly on a production system, I'd
| default to it for any MVP or serious project going forward.
|
| LiveView is also very close to becoming default over React for
| interactive Frontends.
| bratsche wrote:
| I feel similarly, except for the AlpineJS part. I think PETL is
| fantastic and I would 100% choose that for my stack.
| rozap wrote:
| I also went this route, but am keeping the infrastructure
| simple in order to minimize lock in. It has been super
| productive but also I've spent years using elixir
| professionally and unprofessionally so I'm comfortable with it.
| The nice thing is that the elixir ecosystem is so robust you
| don't need to get locked into whatever cloud provider solution
| is in vogue at the moment. Also, we got a pile of cloud credits
| from different providers, and intend to use them :)
| scwoodal wrote:
| I also would choose Elixir/Phoenix. Having spent my career in
| Python/Django, Elixir/Phoenix/Live View is on another level of
| productivity.
|
| For anyone needing a reason to jump into Elixir, take 40
| minutes and watch this talk [1] by Sasa Juric. He communicates
| things so well as to all the benefits of Elixir/Erlang/BEAM.
|
| Then take the time to read Elixir in Action book (again, Sasa)
| and you'll be off to the races.
|
| [1] https://www.youtube.com/watch?v=JvBT4XBdoUE
| Leftium wrote:
| SvelteKit hosted on Vercel serverless functions.
|
| - Userfront for auth
|
| - Not sure yet about DB/persistence... Supabase? FaunaDB? MongoDB
| Atlas? Simperium?
| nikivi wrote:
| Trying to make Solid/ChiselStrike stack work. It has its rough
| edges but I am trying to iron them out so its reusable for all my
| projects going forward.
|
| https://github.com/learn-anything/learn-anything
|
| Reasoning behind the stack is that I feel productive in Solid and
| it's plenty fast on first load and as SPA when fully loaded. I
| love the component model and JSX.
|
| ChiselStrike is new to me but I was looking for something that
| lets me declaratively manage my schema. I checked
| https://entgo.io (it produced too many Go files to my liking),
| also Prisma (https://www.prisma.io), found it bit complex to get
| started with.
|
| I also checked https://www.edgedb.com and it's nice but with
| ChiselStrike I can deploy it with LibSQL (fork of SQLite) and
| replicate it so responses should be plenty fast and I can build
| on top more easily.
|
| For native apps will use SwiftUI composable architecture when it
| comes to it. React Native code sharing seems nice but Solid
| doesn't have a React Native alternative yet sadly.
| awb wrote:
| Current word count:
|
| * javascript / js: 95
|
| * rails: 89
|
| * django: 86
|
| * postgres / postgresql: 77
|
| * react: 75
|
| * python: 52
|
| * supabase: 52
|
| * elixir: 44
|
| * ts / typescript: 41
|
| * nextjs: 31
|
| * sqlite: 29
|
| * laravel: 28
|
| * vue: 27
|
| * phoenix: 27
|
| * net: 26
|
| * htmx: 23
|
| * node: 23
|
| * html: 20
|
| * github: 20
|
| * tailwind: 18
|
| * rust: 18
|
| * ruby: 18
|
| * aws: 17
|
| * vercel: 16
|
| * prisma: 16
|
| * docker: 16
|
| * graphql: 15
|
| * firebase: 15
|
| * php: 14
|
| * flask: 13
|
| * svelte: 13
|
| * hotwire: 13
|
| * liveview: 12
|
| * curl: 12
|
| * grep: 12
|
| * bootstrap: 11
|
| * fastapi: 11
|
| * spa: 11
|
| * java: 11
|
| * linux: 10
|
| * express: 10
|
| * sveltekit: 10
|
| * go: 10
| v3ss0n wrote:
| won't be fair if you don't seperate frontend and backend ,
| because theres no much choice in frontend land other than
| JavaScript.
| aluminum96 wrote:
| Angular and Express. I'm familiar with it and it's easy to
| iterate fast with what you get out of the box.
| ilaksh wrote:
| I mean for me it comes down to what I am most familiar with. I am
| old so that means things like Digital Ocean and Express.js with
| plain old JavaScript. I guess I should not admit that publicly.
| Or privately.
|
| But also if I was slightly less old I think I would be heavily
| into Python at this point especially as far as the ability to
| easily leverage data and AI tools and libraries.
|
| But again, my suggestion is go with what you are familiar with.
| And if you are less old and are excited about a new language or
| framework, that seems perfectly valid to me. The hard part about
| programming is staying motivated. So if new stuff helps with that
| then great. I
|
| One more take is that you should start by defining the problem in
| detail before you make up your mind on the architecture and
| technologies that you will employ. If there is a particular
| technology that is well suited or has a ready-made solution, you
| should consider that.
| gls2ro wrote:
| If it is a SaaS 100% Ruby on Rails
|
| Why:
|
| - has almost everything that I need usually in mature gems -
| battle tested in production
|
| - speed of development
| lta wrote:
| I did so last year, and I cannot be happier. My only regret is
| that I wasn't aware of htmx/hotwire at the time. I went with
| Vue, and I regret it immensely.
|
| Rails is the fastest development platform I've tried so far, it
| is predictable, well crafted, structured yet flexible. You
| can't go wrong with it.
|
| Every now and then I try something new on a side project or I
| have to work on some other codebase for my customers, and
| nothing so far has tempted me to move out of rails for my
| serious projects
| sureglymop wrote:
| I used svelte and it's been super simple and efficient.
| treis wrote:
| IMHO, part of this is that people have accepted the poor
| experience of non-realtime applications. But there's a huge
| UX improvement if the application responds faster than users
| can input actions. Doesn't matter for all applications but if
| your users are going to spend significant time inputting data
| it makes a huge difference.
|
| Also IMHO, a flexible type system like Typescript makes
| development faster than without it. You can refactor faster,
| it catches silly mistakes, and you don't have to write as
| many tests.
|
| Rails does a lot of great things for you, but IMHO ultimately
| it's stuff you don't really need. If there's any chance that
| the application will grow beyond a few developers I think it
| hurts more than it helps.
| weaksauce wrote:
| with hotwire you get the benefit of having that SPA with
| quick responsiveness but with the much, much reduced
| complexity in stack with all the jankiness that that brings
| with it.
| aantix wrote:
| >If there's any chance that the application will grow
| beyond a few developers I think it hurts more than it
| helps.
|
| Simply not true.
|
| I've consulted on multiple teams across products built with
| Rails. Products that supported hundreds of millions of
| requests and generated a similar levels of revenue.
|
| Rails scales - programmer productivity, traffic. It scales.
| RangerScience wrote:
| One thing I've taken to pointing out, and it seems like
| you have way more experience with which to back it up -
| is that it's not just about scaling _to_ millions, it 's
| also about scaling _from_ zero.
|
| Thoughts? :)
| treis wrote:
| >Simply not true.
|
| It's not true that I think it hurts more than it helps?
| boredtofears wrote:
| > part of this is that people have accepted the poor
| experience of non-realtime applications
|
| my experience has taught me the exact opposite: people have
| accepted the poor experience of real time applications
| (client side crashes that bring down the entire page, half-
| baked routing that is essentially just rebuilding the
| browser navigator, inconsistent client vs server rendering
| processes). developers tend to completely stick their head
| in the sand when these issues are occurring. there's
| complete classes of problems that simply go away when
| you're not building an SPA.
|
| > Also IMHO, a flexible type system like Typescript makes
| development faster than without it. You can refactor faster
|
| in the long run, yes, but in the short term you're probably
| not going to get your mvp out faster because you chose TS
| treis wrote:
| > people have accepted the poor experience of real time
| applications (client side crashes that bring down the
| entire page, half-baked routing that is essentially just
| rebuilding the browser navigator, inconsistent client vs
| server rendering processes).
|
| People complain about that stuff all the time.
|
| >stick their head in the sand when these issues are
| occurring. there's complete classes of problems that
| simply go away when you're not building an SPA.
|
| Well, yes. If you don't actually build a real time
| application you won't get the benefits of a real time
| application.
|
| >in the long run, yes, but in the short term you're
| probably not going to get your mvp out faster because you
| chose TS
|
| Once there's even a moderate level of complexity (i.e.
| 2-5 devs for 1+ months) the type system helps you catch
| issues. Even if it only saves you one 4 hour debugging
| session you come out ahead.
|
| That assumes you sit down and write out your MVP without
| any significant refactoring. If you do have to make
| changes then TS will save you significant time there.
|
| It also assumes that you're not writing tests that
| duplicate what a type system does. If you do write those
| tests then again I think you're slower.
|
| Rails does have the advantage of there generally being
| one "Rails way" of doing things. That can short circuit a
| lot of design discussions and other sorts of
| bikeshedding. But you can also just not do that and,
| IMHO, come out better.
| mindcrime wrote:
| I'm vaguely aware of htmx, but have never used it. Had not
| heard of hotwire until just now, but that looks _really_
| interesting. Thanks for the pointer!
|
| Would you care to say any more about your experience with
| Vue? I've heard a lot of good things about Vue and had it on
| my mental "things to learn one day" list for a while. Would
| be really interested in hearing any counter-points from
| somebody who hasn't enjoyed working with it.
| jmuguy wrote:
| I'm not sure what their particular beef with Vue is but
| I've been using it for several years now with Rails and its
| mostly been great.
|
| They had a similar issue as Python, albeit not nearly as
| bad, with their upgrade from version 2 to 3. It required
| some rewriting. They also introduced a new core concept
| with the "composition" API, which completely changes the
| way Vue apps are written. Luckily once you made a few
| required changes you could continue writing apps like you
| used to, ignoring the new composition API. I'm assuming at
| some point we'll be forced to change, which will suck.
|
| One thing we do, which I don't think is as common when
| using Rails with a heavy frontend like Vue or React, is
| that Rails is _not_ in API mode. That is Rails still
| handles routing, pages are still rendered in ERB, and then
| each page is its own little Vue app. So we can use Rails,
| Ruby, etc to initially hydrate the pages and inject stuff
| by calling to_json on it. This also means we can let Rails
| and Devise handle login and session, which I absolutely
| hate doing with a pure JS frontend.
|
| Routing and session management are something I think Rails
| is extremely good with. This also means that if a section
| or sections of the site are pretty simple (password reset
| for instance) we can just render the page in ERB, no JS
| required.
|
| Regardless, I still like Vue and it has a pretty decent
| ecosystem. If I had to go back and start again I'd probably
| just go with React. It clearly has the most support (and
| most jobs) on the front end.
| moxplod wrote:
| First I heard of HOTWIRE. I have been using PJAX for a
| decade now, which is a similar concept.
|
| I use .net mvc with a razor templating engine. But this can
| be used with any backend.
|
| It makes it super easy for me to maintain all my UX in
| server-rendered HTML templates. I get a clean SPA with
| super high development efficiency with MINIMAL javascript.
|
| The best part was I could hire any developer and they know
| how to work in basic HTML/JS/CSS.
|
| Edit: Reading more, I might need to spend time looking into
| HTMX/Hotwire as a replacement for PJAX at some point.
| kcartlidge wrote:
| Worth looking into Hotwire. It works well with .NET MVC.
| 0xblinq wrote:
| Check out also Unpoly. It's probably the most "batteries
| included" of this kind of tools, although not as popular.
| evolve2k wrote:
| Can you expand further?
|
| What has you bother to introduce unpoly when Hotwire is
| included by default? Aka, what are the main things
| missing/better that drive you to use unpoly.
| rahoulb wrote:
| I love Hotwire and it's reinvigorated my love of Rails.
| 0xblinq wrote:
| I'm using Laravel with Hotwire and it's fantastic. Now I want
| to cry every time I see the mess of overengineering I have to
| deal with in other projects when they're built with Redux,
| React, etc, etc.
| streblo wrote:
| Which gems do you most commonly use?
| joshxyz wrote:
| For a for-profit mvp my goto answer is always "the one you know",
| fast release matters, fast iteration, fast sales. Optimize once
| you got sensible sales and sensible metrics.
|
| For personal projects, reactjs or vuejs or solidjs, tailwindcss,
| nodejs. Depends though, sometimes there are projects that demand
| the strengths of golang or rust.
| ge96 wrote:
| All JS for me with mysql/postgres and OVH VPS
|
| Node/Express/React (can use next/nest)
|
| NGINX Let's Encrypt
| steponlego wrote:
| Unix + C, Berkeley DB, all on a self hosted Threadripper. Zero
| cloud / SAAS.
| me551ah wrote:
| Backend
|
| .NET Core on Linux - Works really well, C# is a great language
| and quite performant too.
|
| EKS/ECS on AWS with spot instances - works out pretty cheap
|
| Cloud DBs like Aurora or DynamoDB
|
| React for frontend, because of how many libraries are easy to get
| for it.
| vyrotek wrote:
| C#, ASP.NET Core, React/Blazor, SQL Server, Azure
| thrown1212 wrote:
| I've gone all in on Cloudflare for my "stack". R2, durable
| objects, D1, queues, logs, Pages and Workers. It all works
| beautifully, out the box, dev env baked in (wrangler), Internet
| scale.
| fatih-erikli wrote:
| NextJS/Typescript. For the database, maybe Redis, or Mongodb.
| RDMS except sqlite seem to be overkill for an MVP.
|
| For frontend, a picocss-like minimal framework.
|
| Django for the next stage. It's good for blogs, feedback
| management, back-office. Django beats rails. Rails is generating
| (scaffold) code while Django abstracting the CRUD operations.
| Clever abstraction beats generated code.
| euphetar wrote:
| Assuming web app.
|
| 1. Python.
|
| 2. Flask. Pure server-rendered HTML, no fancy frontend. Avoid JS
| as long as I can, just use jinja templates. If my app is not
| going to work with good old HTML and CSS chances are it's not
| going to work at all.
|
| 3. Classless CSS framework. I like this:
| https://watercss.kognise.dev/.
|
| 4. Sqlite3 or Postgres. Prefer postgres because with docker it's
| 5 minutes to set up. I use SQLAlchemy from the start because it
| makes life easier. If you ever deploy and worry about real data
| you add alembic for migrations.
|
| 5. One docker compose for everything.
|
| 6. Cheap VPS for like $3 per month.
|
| That's it. I would like to upgrade my MVP stack, but it's battle-
| tested and it works well. After the 9 to 5 I only have like 3
| brain cells alive so I need to get stuff done as fast as
| possible, which means using what I know.
|
| One thing I often reinvent and reimplement is OAuth. Definitely
| "Sign in with google" is the best way to add auth to your app,
| but it's such a pain to set up.
| kevinak wrote:
| To get started? SvelteKit with SQLite (+Prisma).
|
| To scale: 1. N number of VPSes distributed around the world with
| LiteFS (most likely Hetzner)
|
| 2. SvelteKit and SQLite (with Prisma)
|
| 3. Anycast Service to direct traffic
| SplitVengeance wrote:
| I'm using Supabase, and a flask server for backend. And using
| Flutter for front end.
| prakashn27 wrote:
| backend: NodeJs alone with Express or any webframework for API
| fronend: ReactJs, NextJs, Vercel along with Firebase DB:
| DynamoDB, Redis, FireStore and Postgres (along with Hasura)
| Infra: AWS, Serverless (Lambda, API Gateway), or K8s(containers)
| misc: Cloudflare for Domain management, caching and Analytics
| storage (using workers and key value store)
| brotchie wrote:
| If it's a proper MVP that needs code and can't be validated via
| concierge or other no-code approach: - React
| Vite Typescript (React Query and Hooks*) - Python Flask
| Backend - SQLite or just fsyncing a JSON file to disk on
| each write (it's an MVP!)
|
| Backend API just returning JSON with typescript interface
| describing response contents.
|
| Don't need anything more fancy than this.
|
| * Tried Redux / Redux Toolkit enough to realize for a MVP it's
| sufficient to just hack stat with hooks and contexts, reducers
| are too much b
| Thorentis wrote:
| Django backend. HTMx on the front end. Possibly an SQLite dB in a
| mounted volume, or a postgresql server if I need those features
| and expect more traffic. Might build the django app into a
| container and host on ECS or another container platform (like on
| DO or Vultr).
| justsomeuser wrote:
| - Server: Node.js + SQLite
|
| I know JS very well, so writing HTTP handlers is quite fast.
|
| Node runs on V8, which is probably the fastest runtime for
| dynamic code.
|
| SQLite makes development easier as it's just a file, gives you
| ACID.
|
| - Frontend: React/Mobx/Tailwind SPA hosted on firebase hosting.
|
| I think the concept of JSX (write your HTML with JS) is good as
| it gives you a real language instead of a restricted templating
| DSL.
|
| Tailwind for the fast iteration speed.
|
| Firebase hosting for the simple CLI and fast CDN.
|
| - OS and hosting: Docker running on Google Container Linux
|
| Docker so that the OS level dependencies of my server are defined
| somewhere.
|
| Container Linux as it auto updates and has all the GCP logging
| and monitoring built in.
|
| GCP for the incremental disk snapshots for simple backup of the
| SQLite state.
|
| If I had to scale the service I would add more CPU cores and
| faster disk. I would also move the parts that need scaling to
| Go/Rust, and design the code to make use of the cores.
|
| A few principles I use when choosing tech:
|
| - Avoid distributed state (network boundaries) when possible
| (SQLite instead of SQL server, function calls instead of micro
| services).
|
| - Use tools for their primary purpose. No shoehorning. Issues
| arise when you try to use something for what it was not designed
| exactly for. If you have >3 tools in your stack that you are
| shoehorning, things are more likely to break in the future.
|
| - Things should still work in 10 years with minimal updates.
| Lindy effect. Bet on older tools if possible as they are more
| likely to be around and maintained.
|
| - Good enough vs optimal: stop trying to find the perfect tech.
| Web tech is sometimes messy and imperfect. Opinion over what is
| right changes.
| unsupp0rted wrote:
| > I think the concept of JSX (write your HTML with JS) is good
| as it gives you a real language instead of a restricted
| templating DSL.
|
| I never got this reasoning. In Vue the idea is:
|
| * Write html templates in HTML
|
| * Call javascript from the template to do javascript things
| (i.e. computed properties and methods)
|
| This has always made the most sense to me, conceptually.
|
| Sure Vue gives you a DSL for looping template elements (v-for)
| or showing template elements (v-if), but almost all the typical
| javascript action happens inside typical javascript calls.
| ccorcos wrote:
| I'm keen on this approach for my next project.
|
| Can you share any Dockerfiles / scripts you use to get going
| with this?
| justsomeuser wrote:
| Sorry I do not, although I have been meaning to publish the
| "skeleton" template repo's I have locally.
|
| There are two template repos I use: `web-ui` and `server`
|
| The both have a `sh` dir with common commands in .sh files
| (watch tailwind, watch esbuild, browsersync to serve and live
| reload during dev).
|
| You config Google Container Linux with a `cloud-config.yaml`,
| which can take a bit of time to tailor at first, but after
| that every project uses the same config with small changes. I
| use Caddy to terminate HTTPS (it will auto generate and renew
| certs).
|
| If you have a contact I can message you when I put them on
| Github.
| jcuenod wrote:
| What do you use for auth?
| justsomeuser wrote:
| Just a normal create-user/login form. Or Firebase Auth if
| Google and other sign in's need to be supported.
| ericskiff wrote:
| Definitely still Rails for me, both for personal projects and for
| work. There are so many hidden requirements in SaaS products that
| have been baked into Rails and popular rubygems, getting to build
| on top of all that work is wonderful. It also makes coming back
| to a project to update it in a few months/years standard and
| simple.
|
| If you haven't played around with Rails for a bit, things have
| gotten simpler in the past few years. Doing a quick demo/todo app
| on Rails 7 is delightful. With hotwire/stimulus, you get frontend
| performance that feels like React, but you're writing simple
| HTML/ERB templates and partials and some light JS controllers.
| It's quite nice.
|
| Scaling those apps to lots of complexity is still an interesting
| challenge, and we're leaning towards React frontends on top of
| Rails APIs when the frontend is complex, but if you're building a
| standard CRUD app, Hotwire/Stimulus just lets you motor through
| the build and spend your time/money on user-facing value.
| olav wrote:
| https://pocketbase.io/ Simple, performant, batteries included
| yawnxyz wrote:
| Pocketbase is surprisingly easy to use to build prototypes and
| smaller apps! Love it so much
| petr25102018 wrote:
| My first choice if the product is a good fit would be old school
| Django deployed to a single VPS (no docker). I am creating a
| public starter kit that does exactly that, including the
| deployment part: https://stribny.github.io/sidewinder/
|
| However, there are lots of use cases that would call for
| additional SPA (Vue/Nuxt), or other tech. So in that case I'd add
| it or replace the tech stack entirely. I'd probably avoid
| specialized cloud services, might consider something like
| https://supabase.com tho if the app doesn't need a complex
| backend.
| camgunz wrote:
| I've been pretty deep in backend engineering a while, but despite
| that I strongly try to use Hasura [0] whenever I can. IME backend
| engineering isn't a differentiator, and I've written enough
| REST/GraphQL endpoints/tests/blahblahblah. I think Django and
| Rails are amazing, but if I ever have to use them again I'll
| probably sigh deep and resign myself to sadness.
|
| On top it's probably Tailwind, and if it's just me I'd use
| Svelte, but if it's more than just me I'd use React.
|
| [0]: https://hasura.io
| speedgoose wrote:
| For the backend I would go with Hasura and some Python or
| typescript depending on who works with me.
| Supermancho wrote:
| The number of Elixir/Erlang backend suggestions seems over-
| represented. Not even Phoenix, just a blanket language
| suggestion. This leads me to believe that many posts are throwing
| out their newest stack-fad they imagine would be good for an
| application. I wouldn't take too much stock in the frequency of
| keywords here.
| jononomo wrote:
| After working on a Phoenix project and using LiveView and
| Tailwind it just makes my brain hurt to think of using anything
| else. I expect Phoenix is over-represented here because Hacker
| News tends to attract the smart set.
| mshake2 wrote:
| Would be useful if each poster also included their years of
| experience in the industry ;)
| ggregoire wrote:
| PostgREST, React, AWS
| pictur wrote:
| I am working on a boilerplate as below. I normally use nextjs.
| But instead of dealing with SSR issues I will try to solve it
| with a tool like prerender.
|
| backend: express + prisma + sqlite
|
| frontend: vite + react + react-query + chakra-ui + zustand
|
| infra: cloud run, prerender
| aloukissas wrote:
| Firebase (or maybe Supabase) - because I love a "backend-less"
| stack. It just take less effort (no need to write lambdas). Full
| solution out of the box (DB, auth, storage). If I ever reach the
| limit of this stack, I probably have insane PMF, so I'll deal
| with it then (YAGNI).
| giraffe_lady wrote:
| janet, sqlite, and htmx.
| dcchambers wrote:
| Depends on what the product is. If it's ultimately some kind of
| CRUD app, hard to beat Rails.
|
| I'd probably run it on a managed K8s platform though instead of a
| VPS. At the very least use a managed (postgres) database instead
| of running my own.
| oknoorap wrote:
| [dead]
| mindcrime wrote:
| For a web-app of some sort?
|
| Host: VPS on OVH
|
| Database: Postgresql
|
| Web layer (server-side): Grails
|
| Web layer (client-side): Javascript - probably vanilla, maybe
| React. Bootstrap.
|
| Auth / SSO: Apereo CAS
|
| Deployment automation: Ansible
|
| CI/CD - Jenkins
|
| Issue tracking: Bugzilla
|
| IDE: Eclipse
|
| DNS: Route 53
|
| If I felt the need for dedicated micro-services for the backend,
| I'd use Java and Spring Boot.
|
| If needed, possibly Apache HTTPD as a reverse proxy.
|
| For a lot of stuff that might fall under "other", like sending
| email, or text messaging, yadda yadda, I'd use Amazon services:
| SES, SNS, etc.
|
| For an MVP I'm not sure if I'd even bother building Docker images
| or not. But if/when I had to scale up, then I'd definitely
| package as images and deploy using Docker or K8S. At _some_ point
| if the thing got traction and needed to scale Big Time(tm) then I
| 'd probably go to Amazon EKS or Azure AKS.
|
| If I needed a mobile app... well, I'm not really a mobile
| developer, but I've been picking at learning Flutter. So probably
| would continue with that.
| mcv wrote:
| Probably Svelte + Node.js.
|
| I don't have any experience with Svelte yet, but I hear good
| things about it compared to other front-end frameworks. I'd
| definitely want to separate front and backend.
| Dowwie wrote:
| The question depends on context that hasn't been provided. Are
| you building it alone? Are you creating services where
| performance matters? What type of volume are you anticipating
| within the first 6 months that the MVP is running in production?
|
| It helps to use the best language that your entire team knows. It
| severely limits your startup if the team is learning a new
| language together. Align tech decisions with the capabilities of
| the team, unless the common denominator is Perl. If the team each
| has at least 5 years of development/engineer experience and
| you're going to need to invest in a common language, give Elixir
| and Phoenix Liveview a try.
| iwebdevfromhome wrote:
| While I prefer python for everything else, I'd go with Laravel
| Jetstream[1] for an MVP, just like I did with the last one I had
| to build. It's laravel, you can use Vue (React or Svelte) for
| your views instead of the blade templating language that comes
| with the framework. Jetstream also comes with Auth, user login
| and subscription and other useful stuff.
|
| And for the flavor, I'd just go with DaisyUI[2] again, since it's
| based on tailwindcss and it's what I've been using lately.
|
| In my experience, I can build MVPs real fast with the stack
| described above.
|
| [1] https://jetstream.laravel.com [2] https://daisyui.com/
| falkensmaz3 wrote:
| MOS 6502 ML
| fmxexpress wrote:
| Building an MVP right now. Digital Ocean but may switch to
| Linode. LAMP. Wordpress for web and the API. Delphi for iOS,
| Android, Windows, macOS, and Linux clients. Stable Diffusion.
| dineshkumar_cs wrote:
| Go service with Postgres (without external cache), deployed (SCP)
| in GCP VM
|
| Reducing touchpoint definitely helps at MVP stage. You've to
| trade performance with features (depending on the tool dev tools
| vs CRUD business)
| tannerellen wrote:
| Svelte + SvelteKit with Supabase hosted on Digital Ocean with
| Nginx.
| rockyj wrote:
| T3 (https://create.t3.gg/) + Postgres (RDS). Hosted on AWS, Node
| Lambdas for async / background work.
| johnstorey wrote:
| What a timely question! A couple of friends and I have been
| wrestling with the question, and coming from the enterprise
| world, have been retooling for producing code over producing
| production code for the MVP. We currently are looking working
| with
|
| * Flutter, with FlutterFlow for UI * Pocketbase for quick,
| extendable back end code and basic BaaS * Heavier emphasis on
| market validation and strategy than technology
|
| We set a goal that the MVP is barely a mock-up. The other
| understanding we have is that the backend would have to be 100%
| rebuilt if / when there is traction, but we were able to get to
| work in one web meeting.
| johnstorey wrote:
| Following up, a note on infrastructure. We are cheap, so our
| LAN is Tailscale. One of us provided a Mac mini where we
| installed Dokku to host containers and development servers. For
| internal use we've been very happy.
|
| For exposure to others we'd likely deploy an MVP to the cloud
| in Dokku as well.
|
| For production we plan to use Kubernetes, but that is an
| artifact of our skill set.
| v3ss0n wrote:
| Django and HTMX
| carapace wrote:
| Elm on the frontend, Elixir on the backend.
|
| Elm because then you can mostly ignore JS et. al. You can hire a
| normal person (anyone who can solve Sudoku puzzles) and train
| them up to make working web UI in a week or two. Elm makes that
| possible. It's like what if you could start a professional bakery
| with just an Easy-Bake Oven.
|
| Elixir because it's more approachable than Erlang. Erlang (the
| BEAM & OTP) because it's much closer to the domain (if you're
| making a complex interactive multi-user kind of a thing, eh? If
| not then it doesn't really matter what backend stack you use.)
| wonderwonder wrote:
| My last SAAS was just raw php on the backend with postgres. Raw
| JS on the front end with a little JQuery. Ran for 9+ years, zero
| down time, zero issues. Supported the Marketing and legal
| department of a Fortune 500 company. Old school is they way. It
| does depend on what you are building though.
|
| Recently really started to like Python so would probably try
| DJango.
| adam_gyroscope wrote:
| I'd do python + django + bit.io (serverless postgres; I'm the CEO
| but I built it because I wanted to use it), deployed in a
| container to k8s somewhere. These are all personal biases to what
| I've used and know well; for someone new to backend I'd probably
| recommend next.js + nodepg + bit.io on vercel or similar.
| arcturus17 wrote:
| The ones I know are Django and Express, but I would possibly pick
| up .Net if I had to build a product today.
|
| I'm wrapping up a Python project right now and my next personal
| project or two are going to be .Net apps of certain ambition
| (users, scheduled tasks, a few tables, maybe a sprinkle of real-
| time) so that I have some good foundations come gametime.
|
| For the front-end I'd pick some React flavor.
|
| Data in PostgreSQL.
|
| Cloud provider probably AWS because it's the devil I know but I
| don't care too much.
| ducharmdev wrote:
| Svelte + Typescript & Tailwind, .NET 7, SQLite.
|
| Why? Mainly because I'm familiar with them, and would be most
| productive with these.
|
| I'd almost like to reach for Blazor, but if it's at all public-
| facing, I don't think I can justify using Blazor at this time.
| PaulWaldman wrote:
| >I'd almost like to reach for Blazor, but if it's at all
| public-facing, I don't think I can justify using Blazor at this
| time.
|
| What are your concerns with Blazor for public facing apps?
| ducharmdev wrote:
| Try navigating to the site for the Blazor material design
| library, MudBlazor, on a mobile browser:
|
| https://mudblazor.com
|
| As much as I want Blazor to work out well, those load times
| are too abysmal for me to seriously consider Blazor outside
| of internal apps.
| dbingham wrote:
| Just about to release an MVP.
|
| I went with:
|
| Terraformed AWS/EKS
|
| Docker
|
| Postgres
|
| Node/Express
|
| React
|
| I'm pretty language agnostic, but for webstack I like to use
| Node, because it means I don't have to context switch too hard.
| I'm using the same language on the frontend and backend with the
| same APIs. I only have to keep one standard library in my head
| and a lot of packages are compatible with either front or
| backend.
|
| Whenever I'm working on the web, that's going to be my go to.
|
| I would consider Typescript, but I don't think the cost/benefit
| of Typescript really balances out until you have a team. The need
| to create types and type harnesses for libraries slows you down
| at first, and speed is the name of the game with an MVP.
| innomatics wrote:
| I love Django but think this is a pretty sensible stack for a
| single developer who is strong at JS.
|
| You are still going to have to make a lot of correct library
| decisions to implement key features like auth and a DAL. Nest
| JS is an interesting batteries included approach (haven't
| tried). TypeORM had a lot of issues few years ago but might be
| getter better.
|
| Disagree re: TypeScript though. Most libraries worth using have
| types or are TS native these days. I find myself much more
| productive writing TS on solo projects with less foot gunning.
| pookha wrote:
| svelte, sqlite, postgres, a little bit of dropwizard, Java LTS 17
| (maybe kotlin).
| NetOpWibby wrote:
| - SvelteKit (TypeScript/Sass) for front-end - Deno, GraphQL, and
| EdgeDB for back-end
| ksajadi wrote:
| I went through this exercise recently, looking for a stack for a
| greenfield project which I had full control over. Tl;dr: I chose
| Rails, albeit with ViewComponents.
|
| When I compared the existing frontend backend stacks like Svelt,
| Next, or a Go, Rust, whatever backend + React frontend, the
| amount that's in Rails out of the box is just not even close to
| the rest. From ActiveRecord to secret management, a dynamic
| ecosystem of gems for almost anything and much more, choosing
| another stack just didn't make sense.
|
| Believe me when I say I really wanted to choose React for
| frontend because of its community and ecosystem but for an app
| with a backend that there is so much Rail does for you that you'd
| be spending weeks rebuilding with anything else.
|
| A caveat is that this is Rails + Hotwire and Turbo +
| ViewComponents that makes it a no brainier. The old school Rails
| MVC would have been a harder sell
| zeendo wrote:
| Frontend - Elm + Tailwind (possibly Miso, it has been a while
| since I tried and dismissed it)
|
| Backend - Haskell, Postgres
|
| Infra - My most recent experience is with AWS and ECS but I'd
| likely try out Nomad and HAProxy.
|
| Pretty much any other moving parts would depend on the MVP
| itself.
| zkirill wrote:
| python -m http.server 9000
|
| And Bootstrap, if I'm feeling generous.
|
| When you're trying to validate a product, the last thing you
| should be spending your time on is fiddling with anything more
| complicated than this.
| nathias wrote:
| svelte, supabase, lambdas
| 0xblinq wrote:
| 1. Laravel.
|
| Because:
|
| - Battle proven
|
| - Secure
|
| - Well maintained
|
| - Well documented
|
| - Fully featured (a lot more than others such as Django or Rails.
| Jobs, auth, asset manager, etc out of the box)
|
| - Doesn't hate JavaScript, embraces it (hello Rails!).
|
| - The templating system, Blade, is pretty great...you can even do
| components.
|
| - Opinionated and not that many different ways to do the same
| thing, makes things more consistent
|
| - Performance is good enough for 99.9% of use cases. For the
| other 0.01% add Octane.
|
| - Great, friendly and professional community. Top high quality
| packages with lots of users and well maintained.
|
| - Excellent frontend integration packages in case blade is not
| your thing: Inertia, Livewire, Hotwire, etc.
|
| - Lots of people know it and like it, so easy to hire for too.
|
| - Code organization makes a lot of sense to me (hello Django!)
| noveltyaccount wrote:
| Some of my assumptions - meet customers where they are (need apps
| & web), be able to iterate quickly, minimize tech skills
| required, prefer easy-to-hire skills, worse is better (imperfect
| decisions are necessary to go fast & get customer feedback),
| prefer batteries-included frameworks.
|
| Given my background that means .NET Maui Blazor (aka Maui
| Hybrid). You need two skills: C# and HTML (Razor). One language
| on the front end and back end. Compiles to native code on iOS,
| Android, Mac, and PC; WebAssembly in the browser. On the native
| apps the HTML UI is interpreted, but the rest of the code is in-
| process and native.
|
| Since I want to use .NET, that means the best cloud support is
| Azure. Azure Functions for the API - serverless for frugal
| startup costs. For data store, Cosmos DB in NoSQL mode as a JSON
| documentDB - again, serverless for frugal startup costs.
|
| I'm also very intrigued with using Go and Flutter instead of
| MAUI, but given my background that means a learning curve instead
| of being productive with a language I know well. I think C# and
| HTML are easier (more abundant) skills to hire, but I suspect Go
| and Flutter would attract more open-source-aware developers.
|
| I'm not sure about a front-end HTML framework to go with Blazor.
| It ships with Bootstrap, which is probably file. I'm curious
| about Bulma which looks simpler and Material 3.0 for Web which is
| in alpha and marching toward 1.0 release soon.
| anderfernandes1 wrote:
| I built an MVP that's been running in production for two
| customers entirely in Laravel and Semantic UI (CSS). When the
| need to a better UI was a concern, I added bits of client side
| Vue.
|
| Now I'm rewriting my front end entirely in Svelte(Kit) and
| Tailwind, and keeping the Laravel backend for now. I will
| experiment with more lightweight PHP backends and Rust in this
| rewrite just to see how good (or bad) things can get.
| samhuk wrote:
| Because of the expertise I have, number of packages i've created
| for it, and sheer ease of use, I pretty much always do the same
| thing:
|
| Node.js, express.js, Typescript for the "central command" server
| that acts as any client's first port-of-call.
|
| Central command fans out to whatever tech is required for the
| job. Very typical for me is fanning out to various python Flask
| servers to do ML/image proc/etc. work or connect to GBQ.
|
| PostgreSQL for persistence because it's pretty much the
| undisputed pereto-optimal solution: solves 80% of problems with
| 20% of the effort. Does almost everything you need until you get
| to the big scales, which by then you can afford to just pay the
| wizards to do the Cassandra, Dynamo, Redis, haskell, etc. magic
| donatj wrote:
| Combination of LAMP and Go, which is what I have been doing for
| years. You can knock out a functional MVP in PHP faster than
| anything else and iterate very quickly. Then spots where
| performance is an issue work in some Go microservices.
|
| This has done my team very well for years.
| hudon wrote:
| This is a killer combination. Nothing has beaten the speed of
| iteration with Apache+PHP.
|
| You can also run a Go FastCGI server to deal with whatever you
| don't want to put in PHP (jobs, complex business logic,
| performance sensitive logic, etc. )
| thecodemonkey wrote:
| I would pick whichever stack that I would be most productive in.
|
| A Laravel app hosted with Laravel Vapor (AWS Lambda) with a
| MariaDB database. Would allow me to get up and running quickly,
| at low cost and without having to worry about scaling for a long
| time.
|
| Using Tailwind and VueJS or AlpineJS for the frontend.
| MobileVet wrote:
| This. Your fastest stack is not my fastest stack. If you want
| to learn the 'fastest' frameworks, that is a totally different
| decision than getting an MVP out the door. That is an
| educational one... which is totally valid just not in an MVP
| sense.
|
| The goal of the MVP is ascertaining product market fit,
| everything else is waste. Use what you know and optimize later.
| If your MVP can handle 1m calls a second, you have failed
| (unless it was natively supported by the framework)
| rat9988 wrote:
| I think it's a very reductive view. One cannot try every
| stack to find its fastest stack. This is why people ask about
| other people's experiences. Someone might have a better
| solution, and a convincing argument, so you could try it and
| become more productive.
| xyzzy_plugh wrote:
| I have a relatively terrible answer that I would recommend
| to no one but it works for me. That's the fastest stack for
| me.
|
| The question wasn't "what is the fastest stack" or "of all
| stacks which is the fastest for you" but rather akin to
| "what is the fastest stack _for you_ ". Which is often the
| one that you are productive in.
|
| It's almost always not worth learning a new stack to
| prototype something unless the goal is to learn the new
| stack.
| hot_town wrote:
| you should check out https://wasp-lang.dev then. It's probably
| one of the fastest stacks out there for React + ExpressJS at
| the moment
| shireboy wrote:
| That's usually my take, but I still worry about a few things:
|
| * which stack will still be around in 1/2/5years?
|
| * which stack Will other teammates or future devs be productive
| in.
|
| I'm still searching for a very light, productive open source
| stack that is well accepted and if not future proof at least
| we'll backed.
| RussianCow wrote:
| For an MVP, none of those things matter. Just rewrite it in a
| different stack later if you realize that the one you picked
| doesn't fit your requirements long-term. Worrying about that
| stuff before you have users/customers is just a waste of time
| and energy.
| didgetmaster wrote:
| But does that really happen? It seems that we have a lot of
| bloated, buggy, inefficient code out there because it was
| initially built using something that was 'quick and dirty'
| for the MVP and was never rewritten properly once it caught
| on.
|
| I have clients that still use Excel spreadsheets for their
| database instead of using a real one just because their
| data was initially stored there and they never changed. New
| features were added incrementally over time and it became
| costly to break everything for a complete rewrite. So they
| limp along forever because management won't let them do it
| right until it absolutely breaks.
| RussianCow wrote:
| Yeah, it's definitely a cultural shift from the way most
| software is built today, but it's a better way to do it
| in most cases. I was also assuming a startup environment
| in my comment; established companies can generally afford
| to do more work up front to make the foundation more
| robust, and they are (slightly) more likely to have a
| better idea of what their customers want ahead of time.
|
| But to answer your question more directly, it does
| happen, it's just uncommon. Where I've seen it done
| successfully, the rewrites have been piecemeal, not all
| at once, so that definitely helps with the buy-in factor.
| turadg wrote:
| I'm surprised nobody has mentioned https://redwoodjs.com
|
| Here's why I'd pick it:
|
| 1. One language for the whole stack. It's an MVP so the front and
| back are both changing fast, with changes made by the same
| person, and you don't want to context switch all the time.
|
| 1a. Javascript as that language because it's the most flexible.
| And with TypeScript you can gradually opt into type constraints
| where they help you.
|
| 2. An opinionated full stack like Ruby on Rails that integrates
| all the pieces I need to ship. When you assemble yourself, even
| small version bumps or outdated tutorials can send you down a
| rabbit hole, stealing time from testing PMF. You want someone to
| validate a combination in which all the pieces work together
| smoothly.
|
| 2a. Redwood.js closest to be being the Ruby on Rails of
| JavaScript. I've toyed with it before and got up and running
| quickly. Its opinions took a lot of unimportant decisions out of
| my hands and let me focus on what I was trying to produce. I
| didn't get so far as to confirm this but it also seems to make it
| easy to gradually drop the scaffolding if the opinions and
| simplifications ever get in your way.
| dbbk wrote:
| I've never been much a fan of Node for backends though. There's
| no framework that's as feature packed as, for example, Laravel
| on PHP. And you have to worry about leaking state/memory across
| requests.
| 0xblinq wrote:
| THIS.
| 0xblinq wrote:
| None of these frameworks (next.js, remix, redwood, etc, etc,
| etc) is a even half close to what you need for any non-trivial
| MVP backend. Such as:
|
| - Validations
|
| - Translations/localization
|
| - Error and request logging and auditing
|
| - Security (CQRS, CORS, CSRF)
|
| - Permissions and a way to integrate it with your
| authentication (does supabase handle this? don't know)
|
| - Email sending
|
| - Background jobs
|
| - Caching
|
| - File uploading
|
| - Rate limiting
|
| Several of these very important things are missing for all of
| these frameworks. While most of them come by default or with
| community maintained "de facto" solutions.
|
| I'm yet to see a feature wise equivalent framework in the JS
| world to laravel/django/rails. They're batteries included or
| full stack just on the surface, as soon as you start using them
| you start missing a ton of stuff.
| blodkorv wrote:
| Just php and mariadb. Nothing too facy.
| nwsm wrote:
| Google Cloud Run or some similar scalable container-based
| abstraction. Off the shelf auth and DBaaS.
|
| I have a lot of opinions on frontend stack too but they vary
| based on product.
| v3ss0n wrote:
| Supabase is very resource intensive. Django+drf+
| spectacular+filters+jwt gives you all the perks of supabase with
| - much easier syntax - much lighter weight - alot higher
| productivity - UI auto generation
| Hortinstein wrote:
| I am curious to know more, can you point me in the direction of
| any blog posts outlining this stack? I have been using supabase
| for a few months and for local dev it is pretty heavy
| kiwicopple wrote:
| > _for local dev it is pretty heavy_
|
| We were discussing this in our CLI catchup this morning. It
| seems the Dashboard/Studio is the main culprit here. We'll
| fix it
| logicalmonster wrote:
| You can build basically any MVP in almost any programming
| language and platform.
|
| That said, anybody who gives an answer without knowing what
| they're building first and knowing the tradeoffs involved IMO
| isn't doing things right.
| vishnugupta wrote:
| I'd say hybrid-ish.
|
| 1. Hosting, full on AWS. Because I'm super comfortable with it
| and I get end to end; from domain registry to data store and
| everything in between.
|
| 2. (mostly old school) Web app stack: React, Java/NodeJS,
| Postgres. S3 for doc store fronted with Cloudfront. Reason:
| Battle tested, huge and thriving ecosystem, most of the problems
| are solved.
|
| 3. Lambda for async tasks.
| 999900000999 wrote:
| Flutter/Firebase.
|
| Of course it heavily depends on what your actually building.
|
| I prefer to do most of my logic in the frontend and Flutter is
| great for this.
| manv1 wrote:
| AWS + Node.js + Lambda + Aurora + API Gateway + ElasticCache +
| CloudFront + SQS + MediaLive + MediaConvert.
|
| We scaled up to hundreds of thousands of viewers + telemetry
| worldwide with no issues. Should be breaking into millions real
| soon now with our next few onboarding's.
|
| We also have an express backend for the UI that's running on some
| puny EC2 instance.
| spapas82 wrote:
| 1. Rhel 9 (alma/rocky linux) on a vps (don't really matters
| where, aws, azure, do, hetzner, wherever).
|
| 2. Postgres 15
|
| 3. Python 3.10/Django 4.x served with gunicorn
|
| 4. Jquery and or alpine js
|
| 5. Bootstrap 5
|
| 6. Caddy to serve everything
|
| 7. S3 if a lot of file uploads are needed
|
| --
|
| I'd definitely keep using the same stack post mvp by vertically
| scaling the db, horizontally scaling the app servers.
| dumbaccount123 wrote:
| Prototype in C, commercialise in C++
| wenbin wrote:
| i've been using django/postgres for over a decade. if it were 5
| years ago, i'd use django/postgres for every project.
|
| but recently i would use cloudflare pages, r2, d1, zero trust...
| in many cases, we don't want to put eggs in the same basket. but
| in some cases (eg, building mvp, toy projects...), it's
| convenient to be on an all-in-one platform .
|
| for example, i recently launched a cms entirely on cloudflare:
| https://www.microfeed.org/
| andrewstuart wrote:
| Nodejs plus plain sql Postgres
|
| I used to use Django as a first choice but nodejs/sql is much
| simpler.
|
| React in front end.
|
| Linux server running Caddy.
| conductr wrote:
| I know this is not really in the spirit of the question, as
| asked. But an important consideration after having spent
| countless hours over many years building "MVPs" that ultimately
| go nowhere.
|
| Hire a PHP/LAMP dev for $10/hour or less (or whatever is cheap
| and good enough) + something like digital ocean. Communicate
| effectively the features and milestones and project manage but
| mainly Spend my time on growth
|
| I'm at a point where I can't fathom writing a ton of code myself
| when I am trying to start a business. Programming is a hobby that
| I enjoy, but my time as an entrepreneur is more valuable
| elsewhere. Most likely I'll find the business's largest hurdle
| earlier and, it's probably not a technical one. Then I can decide
| if it's something I want to pursue or pivot to something else.
| readonthegoapp wrote:
| I've done this a bunch
|
| It rarely works for me
|
| Prob a bunch of reasons but - low dev expertise
| - dev burnout bc it's prob a one man shop -
| overengineered too aggressive on my part -- ie too complicated
| for an MVP
| sonovice wrote:
| Pocketbase on a very small VPS for the backend and SolidJS +
| TailwindCSS for the frontend, served using caddy.
| jarek83 wrote:
| I'd go old schoolish-ish with Rails with Turbo or Phoenix
| LiveView (both with PSQL) + maybe some CF Workers.
|
| We see no reason to use extensive front-end as it has only
| downsides now - it loads longer, it exponentially balloons stack,
| it requires to hire front-end guys, it is not needed anymore for
| DOM manipulation.
| bradwood wrote:
| AWS Serverless -- all day long...
|
| Lambda, DynamoDB, API G/W, SNS/SQS, EventBridge, S3, Cloudfront.
|
| Reasons: no servers, no VPCs, no k8s yaml, great tooling, easy to
| deploy (serverless framework, terraform, etc), easy to secure.
| bradwood wrote:
| oh, and extremely _cheap_.
| xupybd wrote:
| It's obscure and different but I'd be using https://safe-
| stack.github.io/ I've never felt as confident about my code as I
| am with F#. It takes a little getting used to and some custom
| widgets are awkward to get working but I love the stack.
| cik wrote:
| Depends what I'm building. When getting it done as quickly as
| possible, I'd rely on Python - Django, and Postgres. If time is
| still of the essence, but not as breakneck, I'll use Python -
| Fastapi and Posygres.
|
| If I have more time, I use go - chi and redis as a primary
| database.
| mbvisti wrote:
| My current go-to are: 1. Go (echo/gin) or Rust(actix/axum) (old-
| fashioned server-side rendered HTML) 2. alpine.js 3. htmx.org 4.
| tailwind
|
| I've found that combination to give me amazing DX and appropriate
| speed of development.
| carom wrote:
| Go web app. MySQL or Postgres. Vanilla HTML/JS/CSS.
|
| Could deploy to a VPS or AppEngine. Can run it locally.
| gorbachev wrote:
| Whichever tech I'm most productive in.
| turtlebits wrote:
| I've been going back to Flask + htmx for quick MVPs. I'd go for
| Heroku or Dokku/Piku (self hosted) for super simple deployment.
| dewey wrote:
| The one you already know.
| hugs wrote:
| Heroku/Node.js/Express/Bootstrap/Three.js
|
| Old school, but it works.
|
| I keep that side of the stack simple because the front-end is
| ESP32/MicroPython/3D-printed-parts/aluminum-extrusions/lots-of-
| motors.
| ajjenkins wrote:
| I agree with that too comments that you should avoid having a
| backend at all for your MVP if you can avoid it (just make a
| static hosted website with HTML, CSS, and minimal JS).
|
| But since you asked about backends specifically, this is what I
| would use. I would use clerk.dev for authentication, Hasura for
| the CRUD API, neon.tech for the database, S3 for static files
| (images), and AWS Lambda for any extra functionality you can't
| accomplish with Hasura natively (but call them through Hasura).
|
| Personally, I like using GraphQL because I can just focus on my
| data model and not think about what endpoints I need to make. But
| there's definitely a learning curve, so sticking with a REST API
| is probably better for most people.
|
| As an alternative, I would also consider Supabase like you
| mentioned. It sounds cool, but I'm already comfortable with
| Hasura so that's what I go to first.
|
| Update: For a website, I would actually use Remix with Clerk for
| auth and Prisma/SQLite for data stuff. That's one of their
| premade starter stacks. I made one prototype with Remix and had a
| lot of fun using it. It's easy to learn and will give you a high
| performance full stack app. My original answer is what I would
| use if you're making a mobile app.
| KerryJones wrote:
| 1. Laravel for backend -- continues to be one of the strongest
| communities & ecosystem and feels beautiful to work with
|
| 2. VueJS for frontend
|
| 3. Hosted on Laravel Forge (using AWS)
|
| 4. Amazon RDS - MySQL (or similar) -- relational databases still
| solve most of the things I need, unless there were specific
| reasons to switch to a nosql
|
| 5. Tailwind CSS
| k0staa wrote:
| Kotlin + SpringBoot + Postgres TS + React AWS ECS
| quadcore wrote:
| Lately I used Redis as main db for a real time app that needs to
| boot where it were.
| skizm wrote:
| HTML, css, js, (maybe jquery and font-awesome if I want to get
| fancy) and all static files dumped in an S3 bucket for as long as
| I can get away with it, then django if I need anything more. Not
| that I think python/django is the "best", but it is what I know
| and it's got all the batteries included out of the box. I've
| never made a sufficiently advanced UI that required
| react/vue/etc. So I still just stick with html/css/jquery on the
| front end.
|
| Semi-related side note: I do use TS/react in my 9-5, but the more
| I use it professionally, the more I'm convinced there is no need
| for it outside of trying to get a job, IMO.
| retinaros wrote:
| I wonder why people like s3 buckets. if your website becomes
| viral it might become expensive
| cj wrote:
| It's pretty easy and free to slap a CDN like Cloudflare on
| top of an S3 bucket
| TekMol wrote:
| Very similar to my approch.
|
| One difference: I am in the process of stripping out jQuery
| from old projects. So I would not use it in new projects
| anymore. Plain JS is just awesome these days. And it is easier
| to reason about event listeners you have set yourself than
| wondering "Where does this mouseover event come from? Maybe its
| from jQueries hover function? Wouldn't that rather use
| mouseenter?".
| shpx wrote:
| Instead of an S3 bucket you can use GitHub Pages. You push
| stuff to the upstream git repo and it gets deployed. It's free
| (you have to pay for GitHub Pro if you don't want to make the
| source code publicly available) and comes with Fastly CDN if I
| recall correctly. You just have to configure your custom
| domain.
| clusmore wrote:
| In the case of static HTML/JS/CSS, the webserver will make
| the source publicly available to your browser anyway, so
| that's not really an issue.
| smackeyacky wrote:
| I use a GitHub action to sync to an s3 bucket, works
| extremely well.
|
| my update.yml: name: Update Website on:
| push: branches: - production jobs:
| deploy: runs-on: ubuntu-latest steps:
| - uses: actions/checkout@master - uses:
| jakejarvis/s3-sync-action@master with:
| args: env: AWS_S3_BUCKET: ${{
| secrets.AWS_S3_BUCKET }} AWS_ACCESS_KEY_ID: ${{
| secrets.AWS_ACCESS_KEY_ID }}
| AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
| AWS_REGION: 'myregion' SOURCE_DIR: 'mydir'
| Fire-Dragon-DoL wrote:
| I wish i could use Go, but we are not there yet framework-wise,
| so I'm either using Phoenix or Rails, depending for the team.
|
| If the code is planned to be a separate React + API app, for
| example because React Native will be used, the I'd use Go
| Towaway69 wrote:
| I recently built a Web based MVP and used Node-Red as backend.
| Frontend was python+flask, postgres and everything dockerized.
|
| I've mainly used sinatra and rails for Web apps and always found
| it difficult to define a clear api on which the frontend was
| based on (I.e in order later to build ios or android apps off).
|
| Using Node-Red forced me to build an api for the frontend, the
| frontend has no direct contact with postgres.
|
| Plus I found it to be more flexible than directly coding when I
| wasn't even sure what the database schema would look like.
|
| Database modelling was done with pgModeler, I.e. No migrations
| and more pgsql functions and triggers.
| petercooper wrote:
| There is so little out there about using Node-Red in this way
| that I would certainly love to see a writeup of the experience
| if ever you fancy it!
| Towaway69 wrote:
| My experience also! It seems NR is only used for IoT and
| hobby projects but it definitely has more potential.
|
| What I use it for is api endpoint, email templates and
| sending emails, websockets and as admin tool (the dashboard).
|
| It requires a lot of discipline to keep the flows separate.
| Reuse of code is a challenge (very tempting just to copy and
| paste code) and generally to maintaining an overview (simply
| because of the number of flows).
|
| On the other hand, business people can immediately see the
| flows and thereby understand the logic. Debugging is a matter
| of connecting a debug node at any point in flow. Background
| jobs (ie sending email) is a matter of splitting the output
| of a node (ie http response is sent and at the same time
| email is triggered or websocket update is sent).
|
| Scalability and production performance remains an open
| question for me. In worse case scenario it would be a case of
| taking the flow.json (my entire backend is a 300k json) and
| building some kind of interpretor from scratch ;)
| hankchinaski wrote:
| nocode
| davidkuennen wrote:
| Database: Postgres
|
| Backend: Go
|
| Frontend: React
|
| App: Flutter
| braindead_in wrote:
| We are currently prototyping Supabase with Nextjs on the
| frontend. Also looking at edge functions.
| pphysch wrote:
| Django. Modern Python has been phenomenal with its choice of
| feature additions (f-strings, type annotations v2, structural
| matching, better timezone support, etc.) and its a language with
| great mindshare right now.
|
| HTMX has been very promising, I have bumped into one or two bugs
| with it but there are always simple workarounds due to the sheer
| surface area of HTTP+HTML.
|
| Postgres for great JSON support, keeping some stuff out of rigid
| schemas is critical for developing MVPs.
| bmikaili wrote:
| SvelteKit+Typescript+tRPC+Supabase.
| torartc wrote:
| I like Svelte Kit for my UI and backend together since most
| things I'm building don't need a public API. It makes it easy to
| work full stack.
| pythonbase wrote:
| The preferred stack will be Django with DRF and maybe some htmx,
| SQLite and deployed on DO app platform.
|
| Alternatively, NextJS with Firebase (or any other cloud DB) and
| deployed at Vercel.
| prh8 wrote:
| I'm currently approaching MVP / ready to pitch stage on something
| and these are my choices-
|
| Rails 7.1 w/ Tailwind (esbuild, not import maps) Postgres DaisyUI
| for Tailwind UI components View Components for Ruby Nothing
| particularly "hot" but there are some newer tools
|
| Post MVP, the only thing I'm looking to change is potentially
| replace a very heavy data analytic background job with a Crystal
| version of it. Will be super easy to port, and since I'm using
| Sidekiq, I'll drop in Sidekiq.cr and thus won't need to make any
| other system changes.
|
| I'm thrilled about it, it's taken a month to go from zero to
| everything working and I'm just tidying up the marketing site
| clivestaples wrote:
| Sounds great. Curious, what did you use for auth?
| prh8 wrote:
| I'm using Devise. It's rock solid and goes along with a
| general sense of "use trusted solutions" for me. I will be
| adding Omniauth and the Devise plugin for it, but that will
| be the extent of what I need in the future.
| edmundsauto wrote:
| Supabase for storage, lambda for backend processing (Twilio,
| mainly). Front end is all hand written js, pages are statically
| generated in Hugo. cloudFlare Pages to host.
|
| All free, scalability won't be a problem since it's a niche app
| and db r/w work is minimal. I estimate I can support 10k userbase
| all for free.
| jl6 wrote:
| I have to say, it's pretty symptomatic of webdev to see hundreds
| of suggestions of solutions before having the slightest whiff of
| what the problem is.
|
| Having said that, the answer is Python+SQLite.
| q-base wrote:
| Are you building the MVP to make a product or to learn a new
| technology? If the former, then the stack you are most
| comfortable with. Let the challenges come from the product-side.
| If the latter, then take your pick based on the reasoning for
| learning something new. Be it job-opportunities, curiosity,
| whatever.
| nvln wrote:
| I'm building the MVP to make a product and get some market
| feedback / validation.
| MobileVet wrote:
| Then build what you know... always the fastest choice.
| fatnoah wrote:
| I agree with this. .NET isn't sexy, but I can do it in my
| sleep. Throw in a reasonable front end framework, and I can
| spend my time getting feedback and iterating. Once I need
| to grow and scale, I'll put more thought into the right
| tech for that job.
| gardenhedge wrote:
| Remix Run
| telecomsteve wrote:
| A web3 stack, everything client-side and peer-to-peer.
| HTML/CSS/JS for front-end. JS/blockchain for backend. JS client-
| side storage/compute, JS libp2p library for peer-to-peer
| discovery, networking, syncing, updates, user-generated content,
| etc. Blockchain for things that need to be tamper-proof or
| involve payment.
| maxcan wrote:
| Data: Postgres & Hasura (for me Hasura is the goldilocks level of
| abstraction - lets me skip writing CRUD handlers, but doesn't get
| in the way either when I need to do something complex).
|
| Frontend: TypeScript, React, apollo client, graphql-code-
| generator, tailwind
|
| Backend Logic: Lambda functions written in TS, packaged with
| serverless.com, but deployed with Terraform
|
| CI: GH Actions
|
| Deployment: AWS via Terraform. One account per environment under
| an umbrella org.
|
| Because I've used this stack so many times I can get a "shovel
| ready" foundation going in minutes with a skeleton that I've been
| iterating on.
| 0xblinq wrote:
| And god protects us if some day you leave the project and
| somebody else has to come and understand these setups.
|
| I bet you know this very well and you're very productive with
| this, but just imagine the next person having to pick it up.
|
| That's where full stack batteries included frameworks shine...
| you know what to expect and how things fit together, you just
| need to figure out the business logic.
| v3ss0n wrote:
| Hhere is quick survey :
|
| Regarding backend choices: curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i Django
| | wc -l 36 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i
| supabase | wc -l 17 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i rails |
| wc -l 28 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i node |
| wc -l 15 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i elixir|
| wc -l 14 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i phoenix
| | wc -l 7 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i fastapi
| | wc -l 7
|
| For Frontend Choices : curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i svelte
| | wc -l 9 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i React |
| wc -l 34 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i htmx |
| wc -l 15
| tdy721 wrote:
| Deno didnt make the list...
| dimgl wrote:
| For good reason.
| heliophobicdude wrote:
| Curious! Can you please elaborate?
| quickthrower2 wrote:
| Wow, now curl is doing pretty well in the rankings!
| addandsubtract wrote:
| C is winning
| claar wrote:
| Should include Laravel too, which would also be my answer.
| zeeg wrote:
| Laravel is just as big as Django and Rails in adoption,
| definitely should be included
| jtwaleson wrote:
| you left out at least vuejs for frontend
| v3ss0n wrote:
| still collecting frontend parts
| v3ss0n wrote:
| curl "https://news.ycombinator.com/item?id=34530052" | grep -i
| vue | wc -l 14 curl
| "https://news.ycombinator.com/item?id=34530052" | grep -i
| laravel | wc -l 10
| schrodinger wrote:
| tangent: asked ChatGPT to update your code to use for loops and
| voila:
|
| Backend Choices: for backend in "Django"
| "supabase" "rails" "node" "elixir" "phoenix" "fastapi"; do
| count=$(curl -s "https://news.ycombinator.com/item?id=34530052"
| | grep -i "$backend" | wc -l) echo "$backend: $count"
| done Frontend Choices: for frontend in
| "svelte" "React" "htmx"; do count=$(curl -s
| "https://news.ycombinator.com/item?id=34530052" | grep -i
| "$frontend" | wc -l) echo "$frontend: $count" done
| v3ss0n wrote:
| Ask chatgpt to collect every possible frontend and backend
| frameworks form this post.
| Towaway69 wrote:
| But doesn't that ignore the negative comments, e.g. don't use
| rails! /s
| v3ss0n wrote:
| for that case we need to build a language model :D
| Towaway69 wrote:
| Grepgpt? ;)
|
| Edit:
|
| apt install grepgpt
|
| Downloading 0% of 5GB #......
| rglover wrote:
| Joystick [1] using MongoDB as the primary database. Run a few
| instances on VPS and then a load balancer in front. This is how I
| run my site [2] following a massive amount of headaches and
| random downtime fighting w/ a k8s cluster. Zero downtime since I
| moved it over in October. Only thing I don't like is I'm using a
| third-party DB host for Mongo (ScaleGrid) which has unfortunately
| gotten quite slow over the past year. Planning on moving this to
| a self-managed VPS as well.
|
| [1] https://github.com/cheatcode/joystick
|
| [2] https://cheatcode.co
| ptrhvns wrote:
| Front end: TypeScript, Vite, React, FontAwesome, Radix UI,
| lodash, React Router, zod, SCSS.
|
| Back end: Python, mypy, Django, Django REST Framework, Celery,
| Redis, PostgreSQL
| bob1029 wrote:
| .NET 7 & SQLite.
|
| Because I wouldn't need anything else.
|
| Also, it could potentially be my final stack depending on the
| size of my business & market. The current Kestrel web server
| implementation is extraordinarily fast (i.e. millions of requests
| per second fast). Vertical scaling isn't exactly a problem now
| that we have 2S servers with 256 cores (and beyond).
| pc86 wrote:
| Have you found any good _managed_ places to deploy modern .NET
| apps other than Azure? My experience is you can either use
| Azure, in which it 's fairly abstracted for you but overpriced,
| or you can use something like DO where it's more reasonably
| priced but you have to handle everything yourself.
| kcartlidge wrote:
| Just for clarity for others passing through this thread ...
|
| Current .NET produces stand-alone cross-platform executables
| just like many other stacks.
|
| Unless you're forced to do legacy stuff, there is _no
| Framework_ any more, and _no Windows or IIS_ needed. They
| build and deploy exactly like other ecosystem executables
| because that 's exactly what they are. You can even generate
| a Linux server build from Windows and MacOS. And it also
| works fine with standard container stuff.
|
| By default a .NET web app or API is a stand-alone server,
| with optional https built in, and you can either sit it
| behind a proxy like nginx or you can direct traffic straight
| at it. In summary, forget all the old stuff about frameworks,
| Windows, and IIS. If you're doing your own project and not
| working legacy stuff you don't need any of it.
| barbazoo wrote:
| Looks like you can run containerized .NET apps via GCP Cloud
| Run
|
| https://cloud.google.com/run/docs/fit-for-run
| mdasen wrote:
| Fly.io works great. .NET will generate the Dockerfile for you
| already so it's pretty easy to set it up. Fly.io will even
| give you a hosted PostgreSQL.
|
| DigitalOcean's App Platform should also handle .NET apps as
| easily as anything else.
|
| .NET makes it easy to get your app all set for Docker and
| there's a lot of platforms that will take Docker containers
| or even build them from your repository.
|
| I guess I'm wondering what managed services for other
| languages feel more managed/easy than Fly.io or DO's App
| Platform taking your repository, building it, and launching
| it.
| JoeMayoBot wrote:
| AWS has been aggressive in .NET support in the last couple of
| years: https://aws.amazon.com/developer/language/net/
| bob1029 wrote:
| I think we need to be super precise when we use the word
| "managed". Today, we use EC2/Azure VMs to run a lot of .NET
| 6+ apps. I consider these to be managed resources. My
| involvement with those servers is an email from the
| hypervisor ~once a year politely requesting a reboot.
|
| I don't think .NET has any specific implications regarding
| _where_ the product is hosted. If you are referring to the
| Microsoft insight /Azure integration crap, we use 0% of that.
| pc86 wrote:
| That's basically what I mean. I just want to deploy the app
| and not have to worry about anything OS-related, including
| IIS config, SSL, etc.
| bob1029 wrote:
| That's exactly what I do - I build a monolith using the
| self-contained deployment feature and zip it up to the
| server to run.
|
| The management of certificates, configuration, etc. is
| built directly into any product I work on. Outsourcing
| this stuff to IIS, et. al. is exactly how you wind up
| hating all of this tech in the first place.
|
| Prerequisites are zero if you do this right. I can take a
| blank EC2 server, copy the binaries over and run them
| immediately. I don't even have to install any runtimes or
| SDKs.
| kbrannigan wrote:
| How do you setup your webserver. This is the most
| challenging part for me.
|
| Here's my process. Build locally, publish, upload to
| server, dotnet run... Now what?
| bob1029 wrote:
| Modern .NET contains the web server. It's not an external
| thing anymore. You include a .NET library to host your
| stuff. Check out the minimal api reference:
|
| https://learn.microsoft.com/en-
| us/aspnet/core/fundamentals/s...
|
| https://learn.microsoft.com/en-
| us/aspnet/core/fundamentals/m...
|
| Literally everything runs inside your process now,
| including the database if you go for SQLite.
| seattle444 wrote:
| C# is heavily influenced by golang now. Run with 0
| dependencies. Web server bundled.
| hot_town wrote:
| 4. Wasp (https://wasp-lang.dev) because it's the fastest way to
| build a full-stack React + NodeJS web app. You can build a prod
| ready proof of concept in a couple hours. E.g. Google OAuth2 is
| configurable in ~ 10 lines of code --> here's proof:
| https://youtube.com/shorts/-daNTYiUC64?feature=share
|
| (disclaimer: I'm the guy in the Video :):):):):)
| ipaddr wrote:
| Laravel because I want to focus on building
| 0xblinq wrote:
| Found the real senior developer.
| vbezhenar wrote:
| Frontend: React + React Query.
|
| Backend:
|
| * Java Spring if it looks like monolith.
|
| * Golang if it looks like microservice architecture.
|
| Postgres for data.
|
| S3 for blobs.
|
| RabbitMQ for queues.
|
| Kubernetes for infrastructure. Managed or self-hosted, doesn't
| matter. One 16GB VPS is good enough for start and can be scaled
| later.
|
| That's my approach to any architecture today.
| champagnepapi wrote:
| you and i have a pretty similar preference!
| gerad wrote:
| Vercel has been great for us for per branch deployments. Just so
| many nice things about having every release and branch ever
| available.
| ryanwaggoner wrote:
| Laravel. I don't have time to fuck around with whatever the
| latest hotness is.
| shanebellone wrote:
| I like Python with custom extensions in C. Python is quick and
| easy. C speeds up the slow bits.
| andyjones11 wrote:
| Elixir, Phoenix, LiveView + Postgres
|
| Main reasons are:
|
| - Can build entire app (with SPA-type experience on the FE) in a
| single codebase
|
| - No need to build any HTTP APIs
|
| - Periodic tasks and managing in-memory state is super easy in
| Elixir. Eventually you might want to stick state somewhere which
| survives restarts (eg redis) but for the sake of moving quickly
| Elixir makes this really easy
|
| - Newer versions of Phoenix/LiveView support html components so
| building out UIs now feels as nice as some of the tools in the FE
| ecosystem
| kcartlidge wrote:
| I like Phoenix/LiveView so it's a nice option.
|
| But I'd probably choose Blazor over it as every one of those
| bullet points also apply to it, it's C# (with which I'm very
| familiar), and if it takes off there are masses of devs
| available in most markets as opposed to handfuls currently for
| Elixir/Phoenix.
|
| Coupled with something like DO droplets and SQLite/Postgres.
| danieka wrote:
| Depending on your use case you could consider using SQLite. For
| example storing auth info in a central database and then having
| one database per customer.
| auggierose wrote:
| TypeScript! TypeScript! TypeScript!
| dirtybirdnj wrote:
| I used to be into CakePHP and then Laravel, I liked the monolith
| style architecture where the template, API, and user interface
| all live together.
|
| I've done backend separated from frontend and while its nice it
| can be a pain to manage on your own, which is usually what your
| doing at MVP time.
|
| Now I'm more focused on using stuff like Strapi or rolling my own
| Hapijs server when needed and having a JAMstack frontend to
| interact with it.
|
| Next.js has been a breath of fresh air to bridge the conceptual
| gap between what I was doing in Laravel (PHP) and now im doing in
| Next.
|
| JAMStack and serverless functions are awesome because you don't
| need to maintain servers anymore. Most sites can be primarily
| static especially when you are prototyping... the data that comes
| from an API can be mocked for demos.
|
| SQLite for DB development without the internet. Being able to run
| tests or do other stuff thats DB destructive without connecting
| to anything. No local server, no nothing. Just you and your flat
| file. Bliss.
___________________________________________________________________
(page generated 2023-01-26 23:01 UTC)