silicea

I work in IT-strategy now, mostly around cloud platforms, architecture and governance.

Some long backstory: I worked as a C# and AngularJS developer a long time ago but am now in a different profession. For this app I used go for the backend (with GORM as ORM) and react (with MUI for components) for the frontend. Go is what really brought me back to coding two years ago since it is a fun language and especially for hobby projects it feels clean and not overloaded. For the frontend I actually started with Vue.js but got frustrated with their state handling and discovered some bugs as well. Then I switched to Svelte wich seemed great if you build everything yourself but the existing component libraries still needed some work. In the end I landed at react. So in that repository I always had the same backend but did two rewrites for the frontend.

From my personal experience I recommend focussing on the architecture and not to overengineer it. You likely do not need a full database at the start, instead sqlite might be enough. You probably can also live without a queue like Kafka or cache like Redis. And your frontend probably does not yet need Redux for state management or even Tailwind for styling. Of course you will have a little more pain when you want to add this later but at the same time your starting complexity reduces and it is easier to maintain the mental model of your application. Once you extend the functionality try to keep as much business logic as possible in the backend (so the frontend can stay "dumb" and focus on UI/UX). Always easier to test the backend. Pick a tech stack and stick with it, knowing your stack is more advantageous than having the perfect stack for every problem. And of course, just get started on something, the growth will happen along the way anyway.

Currently it uses Resend (https://resend.com/) for email sending. You can add your resend token as env variable. The free plan allows for 3.000 mails per month, Meerkat would send you one mail a day at the specified time.

Everything so far was built to scratch my own itch so now I want to build the roadmap based on what others need or want. CalDav definitely sounds sensible, OIDC is also on the roadmap as well as API token support. In a couple of days I plan to post a more structured roadmap and publish it on github.

Depends on your use-case. If you only want to store your contacts go for Thunderbird contacts or Baikal. Meerkat helps you when you want a more user-friendly way to organize everything around those contacts, like relationships between them, a timeline of activities and scheduling for reminders. I also started with a spreadsheet but at some point required something more sophisticated.

Thank you! If anything is unclear or missing feel free to message me or open a github issue. As the maintainer I sometimes can't see the forest for the trees anymore :)

There is an export button in the settings to export all data (aside from profile pictures) as CSV or export the contacts as VCF including profile pictures (but excluding activities and notes). Both of these methods allow for import into e.g. google contacts if you want to migrate away. In general all data is stored in an sqlite database on your file system as well as a folder for the profile photos.

//Edit: To migrate data into meerkat there is also an import assistant in the contact list page that allows for VCF or CSV import

There's quite an overlap in functionality but differences in how it works in detail. Looking for example at reminders, Meerkat shows overdue reminders in the dashboard until you acknowledge them (email reminder goes out only once of course). Then the reminder can be marked done and get persisted into the timeline or you can skip it. You can also set reminders to reschedule from completion date (e.g. you have a weekly catchup, are behind for five days; then the reminder is rescheduled for in a week not for in two days). Or looking at profile photos you can also just copy the image address from e.g. a LinkedIn profile in pull it in via the dialogue without saving it locally on disk. There are many such differences, so best see what works better for you.

Thank you and do open a github issue if anything is not working as expected or the docs are unclear. I used expose in the docker compose file to help other developers understand the application better (expose itself is only for documentation, only 'ports' actually opens a port outside the internal network). Both containers also sit behind an nginx that acts as a single entry point. The /health endpoint exists currently only for docker healthcheck but I like your idea of exposing it through the frontend to allow for Uptime Kuma monitoring. I'll implement that next.

This might be a little throwback: https://wiby.me/surprise/

Every time you open the link you will be forwarded to a random Web 1.0 homepage. There are many great gems to discover.