Show HN: A NextJS boilerplate to automate all the boring stuff | Hacker News Reader

Show HN: A NextJS boilerplate to automate all the boring stuff

shipfa.st

23 pointsmarclou37 comments

Hey HN,

I'm a solopreneur and I ship apps like a madman. 16 startups in the last 2 years.

I realized I was doing the same thing over and over: set up DNS records, connect DB, listen to Stripe webhooks...

So I built ShipFast for 2 reasons: 1. Save time and focus on what matters: building a business 2. Avoid headaches like emails ending in spam or waiting 3 days for Google to approve

I hope this boilerplate will be as helpful to you as it is for me. Would love your feedback pls

Marc

Open articleView on HN

You might consider just releasing this as an open source repo. I’m sure your work is excellent but there is no way I would ever trust such foundational elements to a closed source boilerplate, especially coming from someone whose work I’ve never seen.

I'm 100% open and public about my work and revenue on Twitter https://twitter.com/marc_louvion

& this is what i built: https://marclou.com

I’m having trouble finding the repo for this project. Can you link it?

It uses NextAuth that in my experience works well only on Vercel (and they don't care)

Also please stop using mongodb

> Also please stop using mongodb

Shouldn't be hard to replace with sqlite

> Also please stop using mongodb

But it's the ONLY webscale database [0]

[0]: https://www.youtube.com/watch?v=b2F-DItXtZs

Have you heard of this new db called dev/null? It’s super fast and web scale!

NextAuth also intentionally made username-password authentication difficult to use because they think signing in with your Twitter or Google account is better.

Meanwhile their home page advertises “own your data”.

yeah, and you cant have something like api keys

Didn't know about this. I started a new personal project using NextAuth but without the username/pass features. Might have to reconsider since I may eventually add that back in.

If not NextAuth/Auth.js, then passport.js?

what other good recommendations do you have for auth?

16 startups in 2 years?

Should I too turn every other weekend project into a startup?

Serious question.

> Should I too turn every other weekend project into a startup?

They even have a term of it now apparently - Micro startups.

As someone who has been involved in a couple startups but not founded one myself, my first impression is that it depends. 16 startups in 2 years is impressive in some sense, but less so if none of them brought it any revenue (I have no idea what the case is with the OP).

if the weekend project has a buy button and a product, yes

Does that qualify as a startup? I'd call that a side project but to each their own.

Looking at his own numbers https://indiepa.ge/marclou it's hard to call most of these startups. He's embellishing at best.

(Not criticising your choices, they’re mostly reasonable and opinionated stacks are very useful.)

I’m curious if you can talk about why you went with mailgun, and especially why mongodb. Supabase is my backend of choice nowadays esp for b2b apps.

I've been using Mailgun for 6 years and never had any issue, so it pass my reliability filter.

Same for MongoDB. It's also free, scalable. For now I don't see a reason to migrate. Open to hear your thoughts :)

I used mailgun previously and was pretty happy with it. I'm using postmark now, forget exactly why I switched but I think it was because I can have one account with silo'd API keys for each app.

Is Mongo better than it’s reputation of years ago? My main concern is it might be tricky to make secure. The other is foreign keys. I have used Firebase (also nosql) and that was a bit tricky in regards to when things need to be joined.

As someone who have dealt with it in the past two years, no. If you want to do complex queries (aggregations), it's a huge pain in the ass to do, reason about, and also troubleshoot. Simple things in SQL like joins are more painful to reason about in mongo. Then there's these gotchas, like if you want to do a join using the $lookup operator, then you need to be aware that indices may not apply in certain situations.

On the driver side, the mongo node client has a really convoluted way of performing transactions that it is really easy to screw up where it looks like you're writing your transaction properly, but it actually doesn't get treated like one (did you remember to finalize the transaction session? did you make sure to pass the session handle to every single mongo callout you're making, etc)

If you want something like trigram searches, you'll have to pay for Mongo Atlas, their hosted mongo product; otherwise, you're stuck with a simple fulltext index.

> Javascript or Typescript?

> Javascript :)

Pass

Oof, choosing JS over TS was certainly a choice. Not one that I would have made…

Arguable a reasonable choice to avoid tooling, but if you are going to use NextJS anyway… might as well choose TS

exactly, the build step is there anyway, so why not get "what you're paying for"

Agreed. I refuse to work in a JS-only codebase. For small things, JS is fine, but for really large projects, TS is a must especially when you want to do large code refactors.

Lots of negative comments below which I think are overly critical. I think the stack looks good and I’ve also had no issues with mongo. Will take a look!

And yet, likely still slower than a plain Ruby on Rails app.

This is not a troll, Rails remains one of the quickest, simplest, out-of-the-box ready solutions for a web app.

Every time I am tempted to try NextJS or the JS ecosystem in general, I immediately get frustrated by the fragmentation for what is settled and standard functionality. Typescript is what keeps tempting me, but Sorbet is helping with that.

I would absolutely love a Typescript on Rails.

I miss Rails deeply but when I tried using it earlier this year, I was struck by how limiting the templating system is compared to React. Components, unidirectional data flow, and years of thinking in Hooks made moving back to ERB feel like a step backwards. And that’s saying nothing of the TypeScript piece.

My dream is that we’ll see Rails with React Server Components support.

The ViewComponent (viewcomponent.org) project brings a lot of the benefits of components to Rails views. It makes data dependencies explicit, it makes them testable, and reusable.

Worth checking out, but it doesn't address unidirectional data flow and hooks, since those are not relevant in a Rails context.

Personally, having state on the server and updating html over the wire is far superior to managing client-side state.

As a fellow solopreneur who builds a few apps a year, sorry but I'm not at all interested in something like this. Good luck though!

P.S. love your site designs and layouts. Taking notes!

People forget that this is a starter kit. I see complaints against JavaScript vs Typescript for large projects.

If you need to ship a web app in hours, I can guarantee that nobody will choose Typescript over a more flexible stack.

@marclou I follow you on Twitter and must say that you made a great decision selling your own tool, congrats for that!

Can you explain the choice of JS over TS?

Been using JS for 6+ years and never felt the need to upgrade, so I tried to keep the boilerplate minimal

Makes sense, is you're a 5+ years experienced JS dev.

But a more junior dev (or someone often switching languages between eg JS / Python / Go etc. all day who finds it hard to remember language details) would benefit a lot form the IDE suggestions and validations that can be offered with TS, and move faster at coding with all the extra help from autocomplete and stuff.

So your implicit tradeoff is to optimize for more senior developers. That's OK, but I'm not sure you intended that.

> I hope this boilerplate will be as helpful to you as it is for me. Would love your feedback pls

It’s a commercial product, so you won’t get much feedback as not many HN readers will need/buy this.

Have you considered open-sourcing it?

Reply on news.ycombinator.com