Strapi beta.19.4 released earlier this week bringing DigitalOcean one-click docs, single type examples, squashed bugs, and much more to the repo!
The full list of features and bug fixes can be found on Github and like every release, it really highlights how the community is making Strapi even more amazing. We wanted to start a new series on the blog that shines a brighter light on the important impact everyone has on the code.
In this first post, we took a moment to speak with Roel Beerens and Ralph Maroun about their recent pull requests that made it into Strapi beta.19.4. The two members of the community tackled a GraphQL issue – Password Endpoints – and improved Strapi’s Open API Specification compatibility with AWS API Gateway, getting more features to work with Strapi right out of the box.
Let’s get to know the person behind the screen a little bit better and read through some of their Personal Pull Request Logs!
Roel Beerens is a full-stack developer from the Netherlands who already had some experience with Strapi before contributing to this release. Generally speaking, his process for deciding if he should contribute to the project starts by diving into the documentation and seeing if there are any guides for what he wants to do.
When the docs come up empty, he’ll then do some issue hunting on Github to see if anyone else is working on implementing the feature or fix the bug before finally looking into the core modules. Extending or even touching such a key part of the code can be a bit tricky since it is so frequently updated and subject to change. Keeping that key detail in mind helps Roel focus on scalability and reusability.
The story for this pull requests began when Roel noticed GraphQL didn’t have any password related endpoints while working on a booking platform so he developed his own on top of the default schema. He recently had to reuse his workaround on a new Strapi project and happened to notice someone else needed the same feature on an issue in Github. He decided to share his implementation and once Jim saw it he asked Roel to turn it into a pull request, resulting in its inclusion in Strapi beta.19.4!
The whole interaction left a positive impression and Roel has changed his outlook on working on and with Strapi. He plans on making a stronger effort to first write a widely usable and more basic version of any given feature, trying to avoid custom client code. The idea is to make it as easy as possible to be integrated into Strapi as a whole.
“I wanted to give something back to the community, doing my part to make Strapi as great as we know it is.”
- Roel Beerens
There is of course always more that could be done and Roel would be one of the first to admit that balancing the ideas of simple implementation and specific client requests can be a challenge. It’s a welcome challenge though, making the work more fun for Roel and opening up new opportunities to participate in the Strapi community.#####[Ralph Maroun](https://github.com/rmaroun) – Strapi and AWS API Gateway's OAS Compatibility
Ralph is a technology specialist from the Netherlands and discovered Strapi nearly 2 years ago before recently starting to use it for a new product. He is deploying Strapi as an API Factory on AWS behind API Gateway.
A part of Ralph’s use case was to make use of Strapi’s documentation plugin that generates fully compatible Open API 3.0 Specifications. He was looking to easily import everything in AWS API Gateway.
In theory everything should have worked out, but while trying to import the OAS 3.0 file generated by Strapi into API Gateway, Ralph had a lot of warnings and even some showstoppers while importing the specification. He decided to start digging into each and every one of them, looking to smooth out the process of integrating Strapi and AWS API Gateway.
Reading over the warnings and error messages, Ralph first noticed how not using an identity provider instead of Strapi’s user management would mean he did not need the user-permissions to be a part of his OAS3 documentation. He then studied the documentation plugin source code to find exactly where and when the docs are generated.
Ralph was using an identity provider for authenticating and authorizing his users so he didn't need Strapi’s users management plugin to be part of his Strapi’s Open API documentation.
Knowing he should be able to pick which plugins would be a part of Strapi’s generated OAS 3.0 specification, Ralph went through Strapi’s documentation plugin source code to find where and when the plugin's documentation was generated.
"After a quick analysis of Strapi’s documentation plugin, I found the piece of code that was used to generate the OAS 3.0 file and added a check so that only the right information is generated based on a configurable property." -Ralph Maroun
With that covered, Ralph started tackling other warnings and blocking issues returned by API Gateway. He was happy to find that making other parts of Strapi’s Open API specification optional via configuration solved most of the remaining incompatibilities between Strapi’s OAS 3.0 file and API Gateway's OAS importer.
The end result for Ralph is a smoother and more streamlined integration process as he moves his new project forward!
Behind every Strapi release there are talented developers from around the world working hard to implement new features and fix bugs.
The list of patch notes does a good job of summarizing what exactly has changed, but we wanted to take a closer look at the individual effort behind contributions with this new series we’re calling Personal Pull Request Logs.
All the devs adding to Strapi’s repo have already shared their code, but we wanted to go one step further and share their thoughts.
Tune in next time to hear more about what the community has to say about their contributions to our latest releases.
Check out the changelog on Github for the full list of details for Strapi beta.19.4.