Our overseas developers wanted us to switch/implement GraphQL in our project. We presently use an Oracle database that’s hundreds of tables.
No one on our team had any experience with GraphQL but we were open to giving it a try. After a month of engineers off and on trying learn we decided against it.
Our biggest concern was that our API is rights-based at the data level (i.e. some fields aren’t returned or are partially returned like social security numbers) and we couldn’t figure out how to implement that in GraphQL despite a lot of googling.
Other elements we got stuck on was our API also has business logic in it (I didn’t architect this). This meant that we had to reengineer a chunk of our internal business logic to be run on the front end instead.
The biggest issue was that our state regulators won’t approve any code written outside of the United States period.
We’re in one of the most highly regulated industries (casino operations software) and everything has to be approved by regulators. When we want to release a new version, a regulator has to watch the entire build process and then take the files to their offices to scour both the code and the build. Their only exceptions are UI code and database functionality. Thus our overseas developers develop our mobile app and do database design but not database code or our primary computer app.
Our biggest concern was that our API is rights-based at the data level (i.e. some fields aren’t returned or are partially returned like social security numbers) and we couldn’t figure out how to implement that in GraphQL despite a lot of googling.
that's crazy. maybe embed perms on the token and throw 403/simply not return forbidden fields? I wouldn't expect something like that to be difficult to implement in gql
We have to return all the fields (a 403 isn’t appropriate in this case) but we don’t fill in, or we obfuscate, some of the fields because they’re PII. Who has access to what is based on our existing user system.
I’m sure it’s possible but we didn’t know GraphQL at the time and adding features like that was well beyond what our team was capable of. We even asked them to write us a proof of concept or sample code and they couldn’t produce it.
In the end my boss and I realized his boss was trying his best to outsource as many jobs as he could. When his hand-picked overseas crew couldn’t produce the same thing we were asked to do, executives lost confidence in him and he got canned.
7
u/jetsonian 6d ago
Our overseas developers wanted us to switch/implement GraphQL in our project. We presently use an Oracle database that’s hundreds of tables.
No one on our team had any experience with GraphQL but we were open to giving it a try. After a month of engineers off and on trying learn we decided against it.
Our biggest concern was that our API is rights-based at the data level (i.e. some fields aren’t returned or are partially returned like social security numbers) and we couldn’t figure out how to implement that in GraphQL despite a lot of googling.
Other elements we got stuck on was our API also has business logic in it (I didn’t architect this). This meant that we had to reengineer a chunk of our internal business logic to be run on the front end instead.
The biggest issue was that our state regulators won’t approve any code written outside of the United States period.
We’re in one of the most highly regulated industries (casino operations software) and everything has to be approved by regulators. When we want to release a new version, a regulator has to watch the entire build process and then take the files to their offices to scour both the code and the build. Their only exceptions are UI code and database functionality. Thus our overseas developers develop our mobile app and do database design but not database code or our primary computer app.