As someone who has worked on apps serving billions of requests per day, backed by relatively modest SQL databases, I can assure you that Wanikani’s traffic is nowhere near exceeding what’s reasonable for a SQL database.
Now Wanikani’s app or schema design, or willingness to pay for hardware resources may be a different matter, but switching to NoSQL isn’t a magic bullet for any of that.
In infra work there is no such thing as “maintaining itself”. You have to keep your stack up-to-date, patch when vulnerabilities are found, periodically update OS packaged, etc. Unless the gross of your infra uses managed products like what Google Cloud, AWS or Azure offer.
I didn’t want to be blunt and you being harsh doesn’t help here. What I think is that the WaniKani app and its backend were designed very poorly with all sorts of mistakes an experienced dev would’ve avoided, but because the traffic/load was moderate at best, no one bothered to address the accruing issues. Now it’s kind of too late to start addressing these issues.
Keeping software and firmware up to date is hardly a full-time job. And it can definitely be neglected for a few months at a time without issue.
I wouldn’t say it’s too late to address these issues by any means. It will just take a bit more time to address them is all. When it comes to a system like this, it’s never too late for anything. Worst-case-scenario is a full redesign of the entire thing, and even that is doable. (But obviously we’re nowhere near that point yet)
I’m okay being harsh when it comes to this. I’m not saying anything against WaniKani, the people who run it, its views, outlook, beliefs, or anything else related. I’m only commenting on the technical side and the fact that these problems are not as hard to solve as they’re being made out to be. I don’t like the countless excuses for why “it’s so hard” to do when it’s been done thousands of times before by thousands of different people in thousands of different scenarios. It’s not rocket science. It’s a well-documented issue that has well-tested and time-proven solutions. They’re just not being implemented for some reason, and I chalk it up to a lack of care. Maybe I’m wrong, but it doesn’t seem like it with the information we have at present.
Like I’ve said plenty of times before, I really like WaniKani and Tofugu as a whole. Their products have helped me immensely and I’m thankful for them and happy to give them my money. But I’m also comfortable criticizing them and pointing out issues that I, using my own opinion, deem are signs of a lack of care for and a neglect of their userbase. I agree that bashing on their product as a whole is kind of trashy and not very encouraging. The people claiming WaniKani is “having their lunch eaten” by their competitors or saying that it was “stupid” to buy a lifetime membership… That is not constructive feedback. But pointing out a solution to a problem and criticizing them for neglecting to address it for 4 months straight? I’m very comfortable with that and I think at a certain point it becomes necessary.
I may still be coming off too strong though, and if you feel I’m crossing a line in terms of harshness/directness/criticism then I would be happy to tone it down. I am comfortable criticizing, but I do not want to hurt or upset anybody.
It’s not a full-time job, true, but if your scheduled is already packed with other things, it adds needless overhead. I know the scales are different, but from experience I can say that maintaining infra does take time.
Which is what is happening 
. It is taking time.
I’m not so sure. The fact they had to pull the Summary Page entirely just to cope with tech debt to me is a sign that a major overhaul is not out of the picture. And actually, Jenny did mention that in the original Announcement thread about the Summary Page being gone. However, from a high-level perspective I don’t see how this has sped up development.
I agree it’s not rocket science! The short-term solution would be getting more devs onboard. It’s not happening, so I too would assume Tofugu is not really invested in the product anymore.
No, it’s okay 
.
I just came back after a long bout of not continuing my studies, started doing reviews and looking forward to seeing how well I would be able to do, only to find out the final review screen is gone.
That screen played a massive part in my enjoyment of wanikani, seeing my % of correct words rise and fall gave me a good indication of how I was doing. As well as reviewing mistakes I made in that screen.
The recent mistakes window isn’t nearly as pretty, only shows me the mistakes I made rather than it being a ‘things you did well on’ and ‘things you were wrong about’ feedback sandwich.
I don’t want to be reminded of JUST the mistakes I made, but also what I did well on. Just a psychology thing I guess.
I am actually not sure if I’ll continue using wanikani without that review screen as there is just no enjoyment/feel of progression in comparison to before for me.
Please bring it back post haste. 
I don’t have a particular strong view on this discussion in general, but I did want to mention that although you say “I’m not saying anything against WaniKani, the people who run it”, when you go on to say “I chalk it up to a lack of care”, you are in fact saying something pretty strong against them. So you’re maybe coming off harsher than you intend.
Also, I’d note that it’s a lot harder to add features to a codebase when you’re coming to it fresh and you didn’t write any of it and it’s a patchwork of stuff written by other people over years, than it is if you already know exactly how it works and it’s well designed. Just “figure out how this is put together and whether the odd stuff it does is necessary for some reason or just because the original writer was confused” can easily blow out what seemed like a simple task into one taking much longer. Without having seen the codebase I would be very wary of thinking I could make optimistic estimates about how long tasks “should” take.
Four months is too long no matter what. No matter how hard this issue is to solve, 4 months is too much. 2 months? Okay, I could see it. 3 months? That’s pushing it, but sure. But it’s been four months, and not only is the problem not solved yet, but it’s seemingly no closer to be solved now than it was 4 months ago.
I’ve worked in tech for over 8 years now. Trust me, I know how hard problems like this can be to solve. I know all (or at least nearly all) the reasons why this might be really challenging or how it might be “harder than I expect.” But nobody’s going to convince me that it’s somehow so hard that you can’t make any progress on it at all in the span of 4 months. That’s simply a lack of effort (in my opinion).
And I will also add that saying someone isn’t putting effort into something is not criticizing them as a person, it’s simply criticizing a very specific aspect of a very specific part of their performance, which I think is completely fair and not harsh in any way.
You didn’t just say they weren’t putting effort into it, though - you said they didn’t care, which is moving from a description of what they are and aren’t doing into ascribing a specific negative reason for it. To take just one possible alternative, they might care, but not have the budget to do the work faster.
Which is completely okay, but it would also be nice to communicate this with the user base. So far, a lot of promises of improvements were made, new rollouts hyped up, relevant features removed with only partial replacements and us left to speculate. I feel like none of this is okay.
While I personally have little to do with the WK app itself, the current situation is disrespectful towards other users.
I’m with Iinchou on this one. We’re not currently seeing a lack of budget, we’re seeing a lack of care. It costs zero dollars and zero cents to put out a forum post updating us on their progress. They refuse to do so. They must not care. (Plus they clearly had plenty of budget to put towards other features, it’s just this one that they refuse to touch.)
Capital i on the front, there. 委員長.
Ah thanks for the correction! Will fix it
I’m just going to change my nick so it doesn’t confuse anyone 
You don’t want to partition the data into different tables which would affect the whole application logic, when you could just partition it instead with no consequence to the application layer. And in any case, the problem with migrating a big database isn’t banging out the code (you don’t really need an ORM for that - it’ll help if you have some tool to write migrations, which they should have since they’re using RoR which has migrations built in) but managing the migration in a way that you avoid (excessive) downtime.
I don’t think it’s a bad idea to keep it all in one table and I disagree that SQL is not a suitable backend. It is if you use it correctly, which is true of any persistence layer.
I do agree though that they would have had enough time to fix this in all these months.
You seem to be still somewhat offended by that statement, so I’ll clarify:
My allegation that WK was having its lunch eaten wasn’t meant as criticism, constructive or otherwise. I’ve long stopped caring about WK as a product. What I’m interested in here is a case study of how a successful product seems to have lost its way (if indeed it has). I made it abundantly clear in my post that this was all just speculation: I don’t know the numbers, maybe WK has more users than ever. That said, WK losing out to its competitors seemed like a decent hypothesis for why the company is behaving so seemingly erratically in recent months.
But if I had to speculate why I think WK is having its lunch eaten, then it would probably boil down to the thing you and I agree on: a lack of care. I think users do ultimately pick up on that and it will lead to a bad reputation down the road.
At no point did I say that nobody should use WK anymore, just that I feel the momentum is gone and the product (and its userbase) will probably not grow anymore. Again, all speculation.
It’s true that partitioning would help keep maintaining the current business logic, but imho it does cause downtime if you need to repartition and not every tool/library handles partitioned tables properly. I would still advocate for separate per-user tables long-term as that’s cleaner overall and with enough records, querying and updating a partitioned table adds needless overhead.
I was just musing at that point, you don’t have to take that observation so seriously.
You would have to create a new table whenever you create a new user. That’s generally not how things are done.
What’s the problem with creating a new table?
That depends on the use case, no?
Edit: at this point I am a little curious. What’s your actual experience with managing databases? You seem to have some pretty black and white takes on this.
Well, for one thing if you use any kind of ORM or data mapper or some such, this is going to create a mess because those generally assume that one entity will map to one table. It also seems like a bad idea to have your application code create table definitions on the fly. It’s something you’ll have to code wholly yourself, as it’s not really a flow very well supported by standard tools.
The more usual way to do this is to add database migrations and have them be in charge of the schema, while your application itself only modifies data at runtime. This makes it much easier to iterate on your schema, e.g. if you find you have to add an index later on and you don’t want to have to worry about adding it to thousands of tables (and not knowing whether it really was applied to all of them). It also means you always know what the shape of your data is.
Really, in 11 years of working as a backend developer I’ve never seen anybody do what you’re suggesting and I really don’t see the point of creating so much overhead when you could just partition your table instead? Like I literally don’t understand what kind of benefit you’d get from creating a separate table for each user, you’d just degrade performance and waste a lot of space.
Which would be the point - you have a user and a per-user table containing time-series data of their reviews. I don’t see how that’s a mess.
In an ideal scenario, the table would be created on user creation. Only once. And things like that are supported by standard tools. I personally never had a problem with this sort of design.
I worked for 3+ years on high volumes of time-series data. We tried partitioning. It was a bad idea.
Clean separation of user data, the ability to rollback individual user data sets easily, etc.
I do understand you have way more experience than me, but I am genuinely not buying the limitations you mentioned, sorry 