I tried to build StackOverflow for flashcards (i.e. spaced repetition with collaboration as a first class feature.) After working on it on nights/weekends for ~2 years, I realized my architecture was shit. I started out with Blazor + F# + PostGres, but eventually I realized that syncing offline client DBs to the cloud was a very nontrivial problem. So I moved to event sourcing. Turns out that's not much better - I started to write my own IndexedDB wrapper, then said "you're a moron" and switched to CouchDb/PouchDb/RxDB. I also wanted to support plugins. I thought I figured that out with Blazor, but eventually I realized that more powerful plugins would want to manipulate the DOM directly. Blazor's virtual DOM kills that possibility. So, I'm off the dotnet ecosystem (I am so, so sad to leave F#) and onto Typescript + SolidJS. I would've gone ReScript but that's tightly coupled to React which uses the VDom. Perhaps I should be using Svelte - I'm not 100% on any of this new architecture yet. So my project has not yet entirely failed... I just realized I spent ~2 years on the wrong architecture.
Fair point. In my defense, people say you should pick the tech-stack you're most familiar with: https://news.ycombinator.com/item?id=29626371 Perhaps I'm misusing the word architecture - I guess I really mean tech-stack.
I'm most familiar with F#, so I went with that and Blazor initially (to avoid learning JS). PostGres feels fairly uncontroversial. Perhaps I magpied from there to event sourcing - I still find it surprising that an indexdb-eventsourcing-wrapper doesn't exist. I considered ReScript given my F# background (the two share a similar philosophy/syntax).
Now though, I'm trying to "pick the best tool for the job" instead of "use what you know". AFAIK if you want offline syncing, the best tool for the job is CouchDb/PouchDb. If you want to avoid the VDom, Svelte or SolidJS are the most popular options.
Please let me know if I'm mistaken - perhaps I'm too lost in my own head.
What is the fundamental issue why you keep switching tech stacks?
I'm not an architect or senior developer, and not saying my take is better, but my considerations would be very different.
First, I would want to have a reasonably clear idea of what you want. My first idea when I hear 'stackoverflow for flash cards' is that you want collections of flash cards. I suppose you need some discovery mechanism, and ways for users to upload and share collections. You mention syncing, I suppose that means that every user always has the last version of a collection. What happens if a user deletes all or most of the flash cards in a collection? Will it be lost for the user or will (s)he be able to use an older snapshot of the collection. This would probably make things more complicated.
Then, I would consider the architecture. It is natural to go for a client-server architecture (and at this point I would draw two circles with two arrows pointing both ways between them). This simple architecture is enough for most applications.
The arrows in this diagram represent dataflow. The choices you make determine the actual data that is sent "over" the arrows. In this case you would need a strategy to distribute the flash cards and update them. So, you define the types of messages that the client and server need to handle and define some data structures for them.
So, the next step is to pick an implementation. An obvious choice for the arrows is HTTP. The client and server can then be implement in any programming language, not necessarily the same. The server can use some DB in the backend. So, again you need have some dataflow between db and server, so you can refine the diagram a bit, and define the data that goes over the arrows.
So slowly you can build up a detailed architecture. Note that it is mostly tech-agnostic, implementation should be possible in most programming languages and you can even make multiple types of client.
Even if you decide to redesign, with this method it is easier to keep your design clean and salvage some parts of protocols/structured that worked well enough.
> What is the fundamental issue why you keep switching tech stacks?
In a sentence: better understanding of the domain/problem and changing my philosophy from "build it quickly" to "build it right".
To repeat myself a bit, I started off with the tech stack I was most familiar with (which is fairly uncontroversial) (F#/RDBMS/Blazor (okay I'm not too familiar with Blazor, but I know C#/dotnet a hell of a lot more than I know JavaScript)). I was originally following the maxim "build an MVP quickly", and I more or less did - I demoed that MVP in a YouTube video on the GitHub. However that advice is tactical - I eventually realized why that advice exists. Startups launch an MVP quickly to de-risk their idea and investigate whether a market exists. I am positive this market need exists. (The real risk is whether it's monetizable... but that's another topic.) I always intended this to be offline-friendly, but just assumed that could be something I could tack on after launching an MVP. I started to investigate that after making the GitHub video, and it turns out to be a significant technical challenge. This facilitated my move to event sourcing, which (in theory) can sync occasionally offline clients. Finally, I grew extremely annoyed at how long it was taking to build an event sourced system. Taking a lesson from my "tacking on offline-mode is easy" mistake, I decided to investigate how a plugin system would work. It turns out there are fundamental incompatibilities between Blazor and any reasonably powerful plugin system. Hence finally, my switch to a VDOM-less UI framework (SolidJS/Svelte) and TypeScript. This kicked me off the dotnet ecosystem (and F#), so I'm glad I decided to this this now rather than post-launch. I previously thought plugins could be something that I "just tacked on later."
> I would want to have a reasonably clear idea of what you want.
Begin with the end in mind :) For me I let the advice of "build an MVP quickly" overcome my better sensibilities. Now, I'm attempting to do "steel thread programming" - something that proves out the technology, before I even consider adding business value.
> What happens if a user deletes all or most of the flash cards in a collection? ... This would probably make things more complicated.
Yes - I have many thoughts on how to resolve this. Event sourcing is of great benefit here, but let's not get into that.
> It is natural to go for a client-server architecture
Yep, my GitHub video demoed this architecture. Unfortunately since what I'm building is going to have an offline mode, this architecture is insufficient.
Unfortunately the devil is in the details. You can describe all the high level arrows/diagrams you want - but as I found out when trying to do event sourcing, what really matters is the implementation. For example, to respond to, "you need have some dataflow between db and [client]"... this is a tough, nontrivial problem that PostGres and other RDBMses have significant problems with.
My adventures have led me to believe that when building out a project of any significant technical complexity - you should first start with a "steel thread". Don't just build out something of "minimal viability" - tacking on additional features that you know you want down the line should be proven out. Perhaps not implemented for real, but there should exist a technical proof of concept.
A person should be able to study their flashcards/notes in an offline environment. E.g. on a plane, on a train in a tunnel, where-ever. Also, flash cards are quite personal, and many people have hesitations about trusting them to some cloud-only server. Imagine if Obsidian/VSCode/your-note-app only worked while online. (Heck, look at how much pain Notion is going through trying to support offline behavior.) At the very least there needs to be a way to export their data to some CSV. IndexedDB is a nightmare, but it has a library that lets it easily sync with the cloud (PouchDb/CouchDb). I'd consider Sqlite, but its syncing features/community are significantly smaller than *ouchDb.
Unfortunately MartenDB is on PostGres (which makes it unviable for electron-style clients) and Microsoft Sync Framework looks dead.
Yep, I was originally intending for this to be a PWA. I'm now planning on Electron (or Tauri, if stars align). There may eventually be a PWA down the line, but I think most students will be okay with installing a program. Electron and PouchDb can both use Sqlite/LevelDb/IndexedDB, which is cool because IndexedDB is a slow POS. So on Electron I think I'll use PouchDb's LevelDb adapter, and when/if I start work on a PWA version I'll use PouchDb's IndexedDB adapter.
I feel your pain. I'm a .net guy who transitioned to typescript 5 years ago.
If I may, could I suggest Firebase as something to consider? It has automatic offline sync over indexdb, and you can subscribe your app to data changes to sync all devices etc.
It takes about a day to get your head around how it works, and given your use case you probably just need the Hosting, Firestore + Auth modules.
I use it a lot now in my side projects and it has been life changing in terms of taking away all of the boilerplate code and letting my just write app code.
The main thing that's been scaring me away from Firebase is the vendor-lockin/pricing. My target audience are students who are very price sensitive, and I hear firebase is pricy as heck. I will likely launch this as a freemium service. Sync is kinda table stakes, so it'll need to exist in some capacity for free users.
No users - no launch. I have many conversations with potential users though... I'm 100% positive this is something that people want. E.g. right now the way they solve the problem of collaborating on flashcards is by using _google sheets_ to collect errata on shared decks. https://www.reddit.com/r/medicalschoolanki/comments/f0bj27/o... This workflow involves manually checking the sheets link, downloading it, converting it to the correct format, importing it into your collection, and hope it doesn't override/corrupt your own customizations to a particular card. It's absolutely fucking nuts.
I'm 100% sure it (or something like it) is desperately needed by the world. However, students aren't really well known for paying for software, so this remains a nights/weekends thing.
Great question. I've thought hard about this. I originally built it to be online-first, thinking "you can add offline support later". This is the version that's demoed in the video on the Github - and is over a year old at this point. I abandoned this for multiple reasons:
1. Adding offline support is very nontrivial. It (may) influence your choice of DB and your data schema. This is a type of master-master replication, since the user is the master of their data, and this is quite painful in RDBMS-land. I'm avoiding having to migrate my schema to support offline sync.
2. There already exist solutions that are online-first. E.g. Quizlet, mochi.cards, remnote. I find all their tools for collaboration lacking, despite being online-first... which is surprising. They don't even support something as basic as commenting on a card. This blows my mind. Imagine Github without issues/discussions/pull requests.
3. Users have repeatedly told me that they prefer offline-first. This is probably due to them coming from Anki - a popular open source offline-first program. Anki is my real "competition" - not billion-dollar Quizlet.
Also - hi, it's you! If you're willing to talk shop, you can reach me at my HN handle at gmail.com. Primarily, I'm curious why no one else is building what I am - Github for flashcards. I've met someone who's trying to build Wikipedia for flashcards... but for me personally I'm more interested in something more decentralized. Not like crypto-decentralized, but like "everyone can have their own card/definition of 'Proteus Syndrome'" - i.e. they don't defer to a central authority. I'd love to pick your brain :) No pressure, just an open invitation! My comment here [1] is still accurate:
> If there's only one thing you know about me, it should be that I want Spaced Repetition to become popular. I don't care who makes it popular - it simply needs to be popular. I'll happily talk shop with anyone building a tools-for-thought system and tell you all I've learned.
The carcass of my attempt in dotnet: https://github.com/dharmaturtle/cardoverflow