Project DREAMER is a todo list + time planner + calendar viewer. Dreamer should be fully dockerized and self-hostable, provide a web interface as well as mobile applications, and incorporate complete automated testing and CI/CD. While the project is still just in my brain, it should be my first large-scale project since I started programming.
I decided to build this service because of the death of my previous project - Lazy1922. Although Lazy1922 was definitely not a difficult project, I wasted to much time during the proccess and its debut ended up too late.
I've always wanted an easy time planner that provided drag-and-drop functionality so that I could easily plan my day, however, nothing came close to what I imagined. So here I decided to just build one as my next side project.
The name Dreamer comes from myself. Dreamers are fools that don't care about reality. Dreamers are selfish and only perceive their own goals. Dreamers are failures that do not realize that they are. However, dreamers continue to do what they want to do, from today, to tomorrow, to the day after.
Yes, I'm a failure, whose APP was rendered useless after merely 5 days. Nonetheless, I would do what I like, cause who cares!
- Todo List
- Drag-and-Drop Time Planning
- Flutter - iOS, Android, and Desktop Apps.
- Hasura + Postgres - API, Database.
- Node.js + Express - Authentication Server.
- App routing/login.
- Database modeling.
- Set up auto-deploy to test and production environments.
- Make README.md, with badges showing test, build status, and version number.
- Set up Jest + Supertest for testing, with database mocks working.
- Containerizing Node.js and running tests on image build, while also having environment variables sorted out.
- GitHub repo and actions that can build on master branch commits.
A week later, and we now have some significant progress :)
First, node and Hasura are both containerized and can be started easily with an .env file and docker-compose. Next, we have finished writing Jest tests for the auth server (database calling repository still has to be tested in the future). Then, we have set up automatic Hasura migrations. All migrations will be automatically applied on container startup. Finally, GitHub Actions are set up to automatically run tests and build + push docker containers. SUBARASHI!
Anyway, I also thought about doing README and adding build/test badges first, but I thought that doing it with auto-deploy would be better. However, I would have to get a test environment first, so I guess I'll stop here and move on to some other errands.
Finally produced some working code today.
Authentication Node.js + Express server is complete, currently creates JWTs that can authenticate for user role on Hasura, hosted in a separate docker container.
Would start pushing to GitHub after project is better cleaned up, which would most likely happen tomorrow or the day after.
Another update for infrastructure decisions.
So after carefully reading Hasura docs, I understood that Hasura simply acts as a proxy in most cases, and all I need is an auth server which could provide the right headers by request.
Also, the next-auth email provider doesn't seem to use email + password login, but uses email + magic link (click link in email to login).
And finally, I think it's kinda not that hard to simply write a Node.js server that can generate and renew JWTs, so I guess I'll just do that.
My ultimate concern is that if using the same Hasura + Postgres instance for saving auth information is secure or not. Since I need to validate (Authenticate) user email/password credentials, I would have to do a Node.js -> Hasura connection if so.
So after some thought, I decided to still use Next.js with next-auth as backend.
So the next step, I should start building a docker-compose.yml with Hasura and next.js, and then start building the
Thinking about not doing web frontend. One reason is that I'm not that "fluent" in web development, but the main reason is that next-auth does not suit well with mobile app development.
Still contemplating about how I would do authentication. Here are my options:
- Use an SaaS and call it a day.
- Use another self-hostable auth provider.
- Still use next-auth or passport.js.
- In-house authentication, not so safe tho.
Actually leaning towards doing it in-house. Option 1 is ruled out if I want the whole thing to be fully self-hostable, option 2 seems overkill for self-hosting, and option 3 just seems dumb if I decide not to web version.
We'll see what I do later on.