The Inner-Platform Effect (2006)
15 points by edk-
15 points by edk-
Interesting enough at least for me, I had seen (and miraculously evaded to work on) this kind of system in one of leading banking products; what's more insteresting than my anecdotal experience is that in fintech there's usually their own "Greenspun's tenth rule" — each complex enough fintech product has cleverly hidden and poorly secured way of including some custom SQL code in otherwise sane GUI workflow. Sometimes it's just a text field with SQL filters validation, sometimes it's some kind of radiobutton/checkbox hell of query builders, but it's always somethere there in the system, and some user can potentially add/change it.
Holy hell. I built this exact thing for my $EMPLOYER last year. Its a json->sql translator, but is heavily fortified, uses HQL and other persistence APIs for inout sanitization, only allows very limited update/inster operations on predefined whitelisted tables and columns,has access control, logging and alerting, the whole deal. Someone even built a GUI front-end for it! Only difference from your experience is that I made sure ours is well commented and documented, instead of hidden and obscure.
The thing is, this was needed. It replaced manually running queries on database directly, and I call it an absokute win on every front imaginable. It serves a real business need, which is last-ditch back-office patch/fix.
Having designed and implemented this thing, and watched other people build on top of it over past year, I can see why every fintech/bank would need something like this.
Now I wanna know how othet people do it, because by god building it for 3 weeks was the best time I had at work :)
Well either you broke my hidden-sql-law or there’s another sql form somewhere in the system.
Jokes aside, I see the need, and there should be a way to do it right - I just don’t see a good way. What I saw got recurring problems for several decades; also due to conservativeness of fintech you can’t pull ’bad’ feature from the new version — some bank relies on it. Thus fixes becomes harder and dreadfullier. Hope you got it right tho!
I hope I got it right too lol!
The task building a common API for half dozen update queries. Each individual query was low enough traffic that building separate API wasn't justifiable but collectively there was a real need.
I was able to identify it as json to sql transpiler, and modelled json structure after s-expressions because of course I did, but the pseudo-sexp structure allowed constructing complex queries out of OR/AND/NOT blocks beautifully simple. Created couple of new annotations to whitelist which tables/columns are allowed, type-specific object construction combined with Java persistence APIs and Hibernate and the whole thing is a beut.
I'm very proud of it too. It is almost over-engineered, but other people on team have extended it in past year without having to touch core query construction, and that gives me great confidence at its longevity. Even probed an idea of extracting it as a lib for other teams but the biggest Java team doesn't use Hibernate so it was dropped.
I keep hoping some interviewer would ask me about it because its a great opener, but alas. Everybody keeps asking me about how Spring does dependency injection..
Yeah, call this an antipattern if you want, but it's not at all uncommon in enterprise software, and there's clearly an ongoing demand for it. Salesforce has parlayed a slightly refined version of this model into a $250B market cap.
Ah TheDailyWTF. That was a daily for me for years. Still have their coffee mugs. I think there is a longer form version of this idea by Alex somewhere on there.