> The vendor product stored every customer transaction as a json record in a giant json document.... Adding a new transaction involved reading the entire json document out of the database, then appending the new record to the end.
Does this sound insane to you? Obviously it should, but in the vein of "insane things" I was helping do tech diligence of a potential investment for a fund. The startup's users table also contained the "tickets/booking" data. Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns. These guys had 500+ columns by the time I reviewed it, and were looking for an investment to "scale".
Of course, it's a solvable problem, but as you can imagine everything was designed in some backwards, janky way. That was just the most obvious "wtf" moment.
> Does this sound insane to you? Obviously it should,
I dealt with the exact same thing in my 2nd ever job. Entire customer and product database (with plaintext passwords) stored in a multi-meg public-facing .js flat file that had to finish loading before the app could do anything (with early-2000s internet). And to top it off, the app was a single monolithic file, in a directory with names like index.1.js, index.final.js, index.newest.js, index.45.js, etc etc.
I had enough experience with best practices to go to our CEO and get the CTO fired, and went about rewriting it with git, mysql, and server-side logic with an actual architecture. And then, the windows server it was all running on got pwned into a porn server, and somehow it was my responsibility despite me never having seen this server and not even having admin permissions.
I heard rumor back in the late `90's of an e-commerce site that stored the prices for it's products in the browser cookie. Presumably a motivated buyer could go in and edit the cookie before checkout, although I don't know if that ever actually happened.
The one I’m thinking of stored prices in the HTML form as a hidden field. It trusted the client-submitted value when deciding how much to charge you.
The justification I heard for the ethics of enjoying the home-rolled discount was that it was similar to haggling. The store chose to accept the offer.
Not sure I totally accepted that, but appreciated the creative thinking.
Low hanging fruit that seemed somewhat common back in the day was not verifying prices of items on the backend. So a somewhat technical user could edit the price in the html field of the item to be $10 instead of $100.
Between this and everything being non https - what a time to be alive.
IIRC, an early version of myspace actually used a GET form for login. It immediately redirected, but if your browser was wide enough, and your eye was trained on the address bar and knew what to look for, you'd see the password flash by in plaintext.
This brings back memory: This was the case for a gold-buying website for the Runescape game in the 2000s. You could edit your cookies or other front-end facing information to change the price of items in your cart, so you could buy gold or items for much cheaper than the market rate.
At some point, while the vulnerability remained, they started cancelling orders abusing this and manually checking the orders.
I think you could still find some old youtube videos or threads on obscure forums with enough digging about that topic, that's how I learned of it initially.
I worked at <large tech company everyone hates> and we had this exact architecture. The senior engineer (who went to Stanford and was proud of it) designed this system. I had long arguments with him about how this system wouldn't scale when we launched it, and used real production data to prove that it would happen. No one listened to me, it launched and imploded within a few weeks, and soon after I transferred off the team. The worst part is, that senior engineer was eventually promoted and that system was passed off to an entirely new team to battle with. That entire system was terribly designed, and I think you can guess why.
Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
It astonished me that people can ever think this is a good idea (everything in a single json document) or that anyone who thought it was could ever get funding or even get through any basic customer due diligence.
One part of my work entails entering companies on their death bed and going through their software development and related investments. I see a lot of JSON-storage in the initially well funded ones. They cough up some crap on Firebase, get some tens of millions of dollars in venture funding, burn through, and never leave Firebase.
It's really, really hard to sell systems implemented with these sexylicious clown technologies. Like, extremely hard. Apparently no sane person with money wants to pay a non-trivial amount for a pile of locked in JSON and Python scripts, and I haven't managed to add any insane ones to my network yet.
The small companies without funding that topple over and end up in my way, more commonly they instead put some stuff on a VPS or two, and typically the market values them quite a bit higher.
Fashionable technology choices burn through a lot of investment money. Seems to me like maybe a sign that money has been a bit too cheap a bit too long.
The lock-in is very bad, especially in the auth and user management but migrating out of the JSON-storage isn't easy either. It also encourages bad patterns, like developing stuff straight into cloud functions rather than locally with version control.
Personally I prefer SQL-RDBMS-style data storage in part because it has these algebraic qualities that makes transitions between 'schema'-versions fairly robust and predictable. Extending and transforming JSON-storage is in my experience rather brittle, even if we ignore the hurdles and indirections around export and import in the clown solutions.
You can go with firebase for version N of your application when you have all relations between entities defined. If version N+1 redefines what your documents are, you're looking to write a migration script. That's not so different from SQL with all the joins. But there are people who can't design a data schema for neither a SQL database nor a document store.
Generally something like Postgres or MySQL would have been a better choice in these cases. You can migrate those, as well as handle growth through sharding or clustering, and more easily adapt to changing business or market requirements.
You'll need to recruit differently to build that way, though. Have someone that knows a bit of nginx and Linux, someone able to stitch together a bit of auth, things like that.
Languages with explicit types are also preferable, as a prospective buyer you'd want to have your people become somewhat efficient fast when they start working with the system. If obvious type constraints you kind of have a guarantee that IDE tooling will help with this, whereas Python, Ruby, JavaScript can be rather inscrutable at first glance.
Now, I have a financial interest in these things, it helps me if a system is well built and somewhat easy to evaluate, change and sell, so I have a bias. But in practice it seems that the basic setup of auth, storage and initial business logic takes very little time compared to the time it takes to flesh out the entire system needed to start making a profit, and since most (IT-)companies fail within three to five years it's probably a good bet to try and make the software you build be reusable and/or resellable.
It works great at a small scale. It's really convenient to have all the data at hand and be able to manipulate it directly in your programming language without having to go through SQL, which, no matter how comfortable you may get with it over years of experience and/or no matter how much library/ORM/etc. you throw at it, is always a foreign imposition into your programming language.
If you know beyond a shadow of a doubt that you will never leave "small scale", it's honestly not a terrible approach. It's also easy to define how to backup "the one file that is everything". You also ought to be confident that the worst case of the One File becoming corrupted is something you can deal with. (Although this is an often-overlooked issue in systems design anyhow.)
I've got some systems that have bits and pieces of this idea... but I'm really, really confident they'll never scale any bigger because for the systems in question it's simply impossible they ever would. I've got one that is, for instance, bounded on the set of wiki pages of a certain type that for it to grow into the 10,000s of pages where the approach would finally start to creak (from the "dozens" it has been in for the last several years and to all appearances will remain indefinitely) would require so much human effort to create those 10,000s of pages that I'd certainly have the budget to upgrade the approach anyhow as it would be negligible compared to the rest of the effort.
It also helps if this not something you're loading per HTTP request; in my case it's one-time on startup of a persistent service.
But you need to know you understand the relevant scales, because this is an immense trap if you don't do the math (it's not hard math, but it's math). Your prototypes work well and are easy to write and then are just total trash when they go to production, and presumably, if the engineer didn't do the math in the first place, it will emerge that they don't understand why the system is crashing in production either. Huge, huge trap. I've not quite seen this exact one with JSON files but I've definitely witnessed the "prototype that any experienced engineer could have absolutely guaranteed would not scale in about 5 minutes of examination".
... which while there were other red-gate posts out there, I can't find that one ever submitted as a dup to link the comments about it (this shall be rectified).
You missed the part where they say they felt like a rock star. Different people are motivated by different things. The key is, if you are very hard working try to channel it in a way that will actually benefit you.
Yes, don't let other people channel it towards themselves! You're in a company, - they will fire you when it becomes convenient to do so - don't burn yourself out for them!
I worked very briefly for a company (that I won't name) that did this with elasticsearch. Every customer basically had a customized form for data entry, and every field on that form became a field in ES, even if that same field name and type was on every other form in the system. Eventually they had to contract with another company to run a customized build of ES on a bespoke cluster because they blew past the default 10k limit on the number of fields in ES.
When it became clear that they had zero interest in fixing this, I tendered my resignation and quickly found a new gig with sane architectural principals.
How about reading the entire Json document out of the database, making a copy of that document, updating the copy, and saving that copy to the database...
Is how someone on my old team designed an internal tool
Is this not how you update a JSON column on a db that doesn't have (or you choose to not use for reasons) a native JSON type with a sprinkling of data should be immutable?
One team in my company insists on storing everything related to a target in an MB-size Elasticsearch document and then do all the aggregation client-side, because they already use ES for everything else and don't know how to use a relational database.
> Does this sound insane to you?
Early in my career, a client came to us with their internally developed perl web app that was very slow and asked us to help them. They were storing all of the information as csv files and would do exactly that, read the entire file, add a new row etc...
We explained to them that we should rewrite it for them :)
I don’t understand the confidence that leads to such misuse. I’m NOT a db guy by any means, and yet when I need one I’m carefully looking up things like “what’s the space complexity of compound indices”, at a development stage. Defensive and paranoid. I guess there are a lot of cowboys out there.
Most people who use an index wrong dont understand space and time tradeoffs at all, how to measure if there is a problem, or how to identify what a thing should be in the first place.
Most people who at least think a bit get pretty far before the vendor specific gotchas start biting.
Would it help, though, even in the short term? Making an actual `ticket` table really isn't that much work. If for some reason it is, you can always use an array type, or even shove JSON into a text column. Even if you're not thinking further than an MVP—hell, further than 5pm—one column=one ticket seems the most awkward and difficult solution I can think of.
My best guess is it started as a single ticket column, then maybe a manual migration to quickly add a second when a rat's nest of code was built around the single column already.
the most far-fetched justification I can muster up for this: the UI/user requried a tabular display of all tickets as columns with one row per user ... and they had a UI that only displays DB table contents as-is.
Nah, even for a 5pm demo that just sounds absurd (with up to 500 tickets per user).
> Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns.
I was thinking like, "Oh yeah, they have 5 tickets, so need 5 rows. What's wrong?". And I read it again and found it's the word "column". It must be a big fun to write a query for such tables.
It would be _slightly_ better if the DBMS have array types.
Often they are not scalable, but it is better than thousands lines of copy-and-pasted code.
Honestly this is not necessarily a good reason not to invest. Sure this needs to be fixed, plus whoever allowed this to happen should be replaced but analyzing the business as an investment opportunity and passing because of this is just as insane in my opinion
Execution is what matters in startups, if they either can't find developers who are halfway decent or if a cofounder wrote this, that's a major red flag that they don't know how to execute.
Those types of design, especially the giant json document, has to be part of the reason some companies pushed pretty hard against the GDPR. Imagine trying to remove personal data from such a system.
Does this sound insane to you? Obviously it should, but in the vein of "insane things" I was helping do tech diligence of a potential investment for a fund. The startup's users table also contained the "tickets/booking" data. Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns. These guys had 500+ columns by the time I reviewed it, and were looking for an investment to "scale".
Of course, it's a solvable problem, but as you can imagine everything was designed in some backwards, janky way. That was just the most obvious "wtf" moment.
They did not get the investment.