Firestarter

Having looked into a few options, I think I am settled on the following approach for unit testing FireStarter:

1. Don't use Firebase or Firebase Emulator in the tests

Using Firebase or Firebase Emulator in tests would allow end to end tests to prove certain functions are working. However this comes with some issues.

Firstly testing like this is slow, and so you can only test a small fraction of what you want if you want your tests to run reasonably.

Secondly testing like this can be flaky, as emulator memory leaks or network errors connecting to Firebase can cause test failures.

Thirdly, it is time consuming for the developer to maintain tests like this in my experience, the setup/teardown becomes complex. Testing even simple scenarios gets hairy!

2. Use Jest

Jest seems a reasonable choice, works well with NextJS, and has a good mocking library. Other options might be just as good. I haven't checked them out though.

3. Mock the Firebase API

With the Version 9 Firebase API that lets you import functions directly, it is fairly easy to mock those out using Jest. There isn't much alternative anyway, as NPM packages that do this seem to have gone out of date.

4. Use a separation layer (facade).

I am using a facade called IBackend.ts. This means that the forms interact with IBackend, and can mocked that out in UI tests. I then separately test the backed implementation.

Reasons for this:

1. Simplify front end code.

2. Possible to create different back ends in the future, for example a Parse backend.

3. Simplify tests. More tests, but each test has to test less.

4. Changes to Firebase API doesn't affect components and UI code.

That's it for now. The main message here is that when working on a framework I can think more about these design decisions as there is not really a deadline.

These testing decisions should give the magic of great test coverage, tests that run quickly and reliably while being able to discover real bugs and prove that we are handling all the API error codes that might come back.

Hi IndieHackers!

Firestarter is (will be!) a kit for building a SaaS applications quickly.

This project was born mainly for me, to consolidate how I like to create a web application in a way this is professional, fast to build, runs fast, cheap to run at a low scale, low maintenance (no server admin etc.) and easy to extend using code from the community.

Code at: https://github.com/mcapodici/firestarter
Latest code always gets deployed to: https://firestarter-three.vercel.app/

Why?

There are a few of these around already, and with options like DivJoy with all the insane number of choices, why do we need more?

Well this is the odd thing - I am not doing a bunch of competitor analysis and trying to find a gap. Doing that stuff kind of turns me off and I quickly lose motivation! Instead I am building this for myself, sharing the code as open source, and hoping a few people along the way find it useful.

The reason for this is I want a project I am mildly addicted to, that gives me joy to work on. That is the only way to keep at it in the long term.

Since nothing really succeeds in the short term, this is my strategy. Also part of the strategy is I can't lose: if I make no money or even get not one Github star, I can still use the learning and code to build other stuff, so I would have gained. Plus it is a fun project, well for me, so there is that.

How to make money?

Future money could come from donations, hiring myself out at a good rate to help startups use the stack, done-for-you versions, premium features. Although my goal is the free version will always be awesome and you won't need the premium, but it might save you time.

Tech stack?

In terms of tech, I plan to use:

• NextJS - for static site generation and React bundling
• Vercel - for site hosting and some of the continuous deployment
• Firebase
• Tailwind
• Various Tailwind plugins
• Various unit test frameworks
• Github actions - for ensuring tests pass before deployment
• Github codespaces - for personal development, although end users can use their own computer and tooling if they want.

I have learned some of the pain points of using Firebase so this project will avoid those giving examples of doing things without falling into those traps. For example testing locally using the emulator sounds great ... but don't do that! It is frustrating, slow to start up and can crash alot. I am going to find better methods of unit testing in this project and I have a few ideas to try out.

Future ideas:

• Expand the project to be a basic SaaS with signup, login, some personal features, like a todo list, some social features, like discovery of other people, chat etc.
• Then add more examples of how to do different things, so that using the template is more like taking away what you don't need than adding what you do need!
• Maybe offer to help people who want to use this in their startup, initally for free.

Thanks for reading!

It is early days, the repo looks bare, the README is very bare.

I don't expect you to remember this project based on this, but hopefully as it evolves, and you see the progress you might want to say, clone it and try it out (or get your tech cofounder to try it).

If there is a feature you would like to see, feel free to add an issue, would love to hear from you!