A Groovy journey in Open Source land (GR8Conf Europe)

Direct live from GR8Conf Europe 2016, in Copenhagen, Denmark! This morning, I presented my latest update about the Apache Groovy history, and the latest developments in the 2.4.x and future 2.5 branches. 

Abstract:

In dog years... err... Open Source years, the Groovy programming language project is a very mature and successful one, as its 12 million downloads a year can attest. The Groovy language is certainly the most widely deployed alternative language of the JVM today. But how do we go from a hobby night & week-end project to professionally company sponsored? And back again to hobby mode but joining the wider Apache Software Foundation community?

Guillaume will guide you through the history of the project, its latest developments, and its recent news, outlining the importance of a community around an Open Source project.

Also, we'll discuss what it means to contribute, when it's your hobby or as a paid committer -- what does it change? What it means to join the Apache community, what the impact of professional Open Source is, and more.

And here are the slides:




Get in the flow! The API developer workflow!

What are the activities of the Web API developer? How API tooling should not get in the way of developer's productivity? I presented a talk on this topic at the GlueCon conference:

The API ecosystem provides powerful tools, online services and definition formats for designing, testing, running, or managing APIs. All share common purposes: improve our productivity when developing an API, allow us to collaborate more effectively, or share our creations with the world!

But developers have already invented efficient tactics to streamline their development, gathered experience with and sharpened their tools of trade. The result is that the services or formats mentioned before can actually also get in their way, and interrupt their development flow, as they have to resort to get out of their routine and processes, to use them.

What can API tooling vendors do to reconcile the habits of developers with their tools? 
In this session, Guillaume Laforge, Restlet's Product Ninja & Advocate, will talk about building, versioning & dependency management of API artifacts, scenario & conformance testing, API documentation, continuous integration, multi-environment continuous deployment, and team collaboration! Let’s get back into the development flow!


A five-sided prism polarizing Web API development

At GlueCon, I presented about the 5-sided prism that polarizes Web API development:

How do you tackle your API development? Are you diving head-first in the code to get something quickly out the door? Do you start by defining the API contract, that you'll share between your teams and the consumers? Perhaps you prefer to describe your acceptance tests, explaining the behavior you expect from your API. But if you're a storyteller, you'll probably write some use cases, scenarios, to have a better feel for what your API is all about, and how your users will take advantage of it. Or simply, you already have data lying around that wants to set free, and be exposed restfully to the world.

In this session, Guillaume Laforge, Restlet's Product Ninja & Advocate, will highlight different approaches to Web API development, along with their pros & cons. Whether you're starting with code, a contract, tests, documentation, or data, you'll get a glimpse of light into the tasty book of API development recipes.



How far should API definition languages go?

I had the pleasure of writing an article for Nordic APIs on Web API definition languages.

If you're into the world of Web APIs, you've probably heard of formats like Swagger, RAML or API Blueprint. They allow developers to define the contract of the API, with its endpoints, its resources, its representations, allowed methods, the kind of payloads it understands, the status codes returned, and more.

With the contract of your Web API, you can generate code for your backend implementation or client kits, documentation for publishing the details of your API for your API consumers. This contract becomes a key element of your API strategy: a contract between the frontend team and backend team to be sure to work on the same ground, between your tech team implementing the public API of your company and all the API consumers that will interact with it.

But API definition languages don't necessarily denote all the fineness of your API, in particular its business rules, or how to check that an implementation conforms to a contract or if the implementation follows the style guides of your company, what tests could exhibit the behavior of the API, and more. So the questions I asked myself was how far should API definition languages go!

A web API for each API consumer?

At our disposal, we have so many ways to interact with an API: from a mobile on iOS or Android, from a web application, or from other services or microservices. And all of them have different needs: one wants only a shallow overview of the data, while the other desires a detailed view of a certain resource and all its sub-resources. It's becoming difficult to design an API that caters to the needs of those varied consumers.

So what can we do? There's a trend around providing different API facades for each consumer, as Netflix does with its experience and ephemeral APIs, or how Sam Newman described it in its Backends for Frontends pattern. But such an approach increases the maintenance burden and complexity, and might only really make sense for big enough teams. 

Other approaches exist for customizing payloads for different consumers, without really providing as many derived API facades as you have API consumers. You can take advantage of the Prefer header, fields filtering, custom Mime media types, hypermedia, or Facebook's GraphQL approach.

I've written an article for InfoQ that dives into this topic, and covers all those subjects: "One API, many facades".

 
© 2012 Guillaume Laforge | The views and opinions expressed here are mine and don't reflect the ones from my employer.