RSS

General Data Protection Regulation (GDPR) News

These are the news items I've curated in my monitoring of the API space that have some relevance to the GDPR and API conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is acquisitions their APIs, going beyond just monitoring and understand the details of each request and response.

US Companies Getting Ahead Of EU Regulations

I find it to be a telling sign of the culture at US companies when it comes to their response, or lack of response to EU regulations. I’ve been curating stories from the API providers that I track on when it comes to GDPR or PSD2, keeping a notebook or research that is ready when I get around to diving in deeper. The companies who are openly talking about these regulations and being proactive about responding to them, are usually the API providers who have a strong stance in the US market, and are poised to, or already expanding this reach to Europe. Companies who haven’t made any noise are probably not concerned with the European market, or just hoping the regulations fizzle out I guess?

After diving into my curation notebook the first company to stand out is Auth0, with a variety of blog posts, and resources on navigating both PSD2 and GDPR. Auth0 is in a good position to provide critical authentication and user information management APIs to other companies who are working to comply with the regulations, so it makes sense that they would be getting ahead of all of this. I fully grasp that many companies are simply issuing their press releases stating they can help with GDPR or PSD2, but you can quickly cut through the fluff by looking at how much they’ve invested in their response, materials, and services. Auth0 has a pretty extensive knowledge-base on GDPR, providing PSD2 guidance on their blog, as well as investing in their EU region for a couple of years–demonstrating it is more than just a press release.

I’m working my way through the list of US API providers, and service providers who are being active on the subject of EU regulations. I feel it is an important sign of the strength of the company, and demonstrates a healthy understanding of how regulations aren’t always bad, and that they can actually help industries thrive. I’m actively working on projects involving GDPR and PSD2 in Europe, and I’m eager to develop my understanding of how these regulations are changing the face of the technology industry in Europe, but also how this will impact US companies. I’m hoping that it will begin to shift and evolve the culture around data ownership, privacy, and APIs as industry standards in the US. I feel that as Internet technology matures, we are going to need to view data a little different, otherwise things won’t be sustainable. I’m hopeful that EU regulations can help set this into motion–we’ll see, maybe I’m naive.


US Companies Getting Ahead Of EU Regulations

I find it to be a telling sign of the culture at US companies when it comes to their response, or lack of response to EU regulations. I’ve been curating stories from the API providers that I track on when it comes to GDPR or PSD2, keeping a notebook or research that is ready when I get around to diving in deeper. The companies who are openly talking about these regulations and being proactive about responding to them, are usually the API providers who have a strong stance in the US market, and are poised to, or already expanding this reach to Europe. Companies who haven’t made any noise are probably not concerned with the European market, or just hoping the regulations fizzle out I guess?

After diving into my curation notebook the first company to stand out is Auth0, with a variety of blog posts, and resources on navigating both PSD2 and GDPR. Auth0 is in a good position to provide critical authentication and user information management APIs to other companies who are working to comply with the regulations, so it makes sense that they would be getting ahead of all of this. I fully grasp that many companies are simply issuing their press releases stating they can help with GDPR or PSD2, but you can quickly cut through the fluff by looking at how much they’ve invested in their response, materials, and services. Auth0 has a pretty extensive knowledgebase on GDPR, providing PSD2 guidance on their blog, as well as investing in their EU region for a couple of years–demonstrating it is more than just a press release.

I’m working my way through the list of US API providers, and service providers who are being active on the subject of EU regulations. I feel it is an important sign of the strength of the company, and demonstrates a healthy understanding of how regulations aren’t always bad, and that they can actually help industries thrive. I’m actively working on projects involving GDPR and PSD2 in Europe, and I’m eager to develop my understanding of how these regulations are changing the face of the technology industry in Europe, but also how this will impact US companies. I’m hoping that it will begin to shift and evolve the culture around data ownership, privacy, and APIs as industry standards in the US. I feel that as Internet technology matures, we are going to need to view data a little different, otherwise things won’t be sustainnable. I’m hopefull that EU regulations can help set this into motion–we’ll see, maybe I’m naive.


Just Waiting The GraphQL Assault Out

I was reading a story on GraphQL this weekend which I won’t be linking to or citing because that is what they want, and they do not deserve the attention, that was just (yet) another hating on REST post. As I’ve mentioned before, the GraphQL’s primary strength seems to be they have endless waves of bros who love to write blog posts hating on REST, and web APIs. This particular post shows it’s absurdity by stating that HTTP is just a bad idea, wait…uh what? Yeah, you know that thing we use for the entire web, apparently it’s just not a good idea when it comes to exchanging data. Ok, buddy.

When it comes to GraphQL, I’m still watching, learning, and will continue evaluating it as a tool in my API toolbox, but when it comes to the argument of GraphQL vs. Web APIs I will just be waiting out the current assault as I did with all the other haters. The link data haters ran out of steam. The hypermedia haters ran out of steam. The GraphQL haters will also run out steam. All of these technologies are viable tools in our API toolbox, but NONE of them are THE solution. These assaults on “what came before” is just a very tired tactic in the toolbox of startups–you hire young men, give them some cash (which doesn’t last for long), get them all wound up, and let them loose talking trash on the space, selling your warez.

GraphQL has many uses. It is not a replacement for web APIs. It is just one tool in our toolbox. If you are following the advice of any of these web API haters you will wake up in a couple of years with a significant amount of technical debt, and probably also be very busy chasing the next wave of technology be pushed by vendors. My advice is that all API providers learn about the web, gain several years of experience developing web APIs, learn about linked data, hypermedia, GraphQL, and even gRPC if you have some high performance, high volume needs. Don’t spend much time listening to the haters, as they really don’t deserve your attention. Eventually they will go away, find another job, and technological kool-aid to drink.

In my opinion, there is (almost) always a grain of usefulness with each wave of technology that comes along. The trick is cutting through the bullshit, tuning out the haters, and understanding what is real and what is not real when it comes to the vendor noise. You should not be adopting every trend that comes along, but you should be tuning into the conversation and learning. After you do this long enough you will begin to see the patterns and tricks used by folks trying to push their warez. Hating on whatever came before is just one of these tricks. This is why startups hire young, energetic, an usually male voices to lead this charge, as they have no sense of history, and truly believe what they are pushing. Your job as a technologist is to develop the experience necessary to know what is real, and what is not, and keep a cool head as the volume gets turned up on each technological assault.


Revisiting GraphQL As Part Of My API Toolbox

I’ve been reading and curating information on GraphQL as part of my regular research and monitoring of the API space for some time now. As part of this work, I wanted to take a moment and revisit my earlier thoughts about GraphQL, and see where I currently stand. Honestly, not much has changed for me, to move me in one direction or another regarding the popular approach to providing API access to data and content resources.

I still stand by my cautionary advice for GraphQL evangelist regarding not taking such an adversarial stance when it comes to the API approach, and I feel that GraphQL is a good addition to any API architect looking to have a robust and diverse API toolbox. Even with the regular drumbeat from GraphQL evangelists, and significant adoption like the Github GraphQL API I am not convinced it is the solution for all APIs and is a replacement for simple RESTful web API design.

My current position is that the loudest advocates for GraphQL aren’t looking at the holistic benefits of REST, and too wrapped in ideology, which is setting them up for similar challenges that linked data, hypermedia, and even early RESTafarian practitioners have faced. I think GraphQL excels when you have a well educated, known and savvy audience, who are focused on developed web and mobile applications–especially the latest breed of single page applications (SPA). I feel like in this environment GraphQL is going to rock it, and help API providers reduce friction for their consumers.

This is why I’m offering advice to GraphQL evangelists to turn down the anti-REST, and complete replacement/alternative for REST–it ain’t helping your cause and will backfire for you. You are better to off educating folks about the positive, and being honest about the negatives. I will keep studying GraphQL, understanding the impact it is making, and keeping an eye on important implementations. However, when it comes to writing about GraphQL you are going to see me continuing to hold back, just like I did when it came to hypermedia and linked data because I prefer not to be in the middle of ideological battles in the API space. I prefer showcasing the useful tools and approaches that are making a significant impact across a diverse range of API providers–not just echoing what is coming out of a handful of big providers, amplified by vendors and growth hackers looking for conversions.


If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.