Blogposts of our JCorians

Spring Cloud Messaging using Kafka

“What is this Kafka I’ve been hearing about?”

In short, Kafka is a horizontally scalable streaming platform. In other words, Kafka is a message broker which can be run on multiple servers as a cluster. Different data streams are called topics. Producers can place messages on a topic whereas consumers can subscribe to topics. Topics can be configured for single- and multiple delivery of messages. Consumers can be grouped in so called consumer-groups, which makes it possible for multiple consumers to act as one when it comes to single-delivery.

But don’t take my word for it. There’s a lot more to Kafka than I can get into in this post and the original documentation is much clearer, so check out the documentation at https://kafka.apache.org/.

“How do I use Kafka in my Spring applications?”

Among all the abstractions Spring Boot delivers there is also an abstraction layer for using Kafka, called Spring Cloud Stream. The use of the cloud messaging API makes it very easy to produce messages to Kafka and to consume them.

Continue Reading

Automatically generating your API from a swagger file using gradle

Normally when using swagger, you generate a swagger.yaml file for your API. But what if you already have a swagger.yaml file and you want to generate the API interface and models, like you would also do with a webservice using a WSDL file? To achieve this, swagger has a great tool: swagger-codegen. The tool has a CLI and a maven plugin, but no gradle plugin. So how do we use it with gradle?

Here is a list of things we need to do to get it to work:

  • Create a gradle task that generates the API interface every time we build (which should be generated to src/generated/java to keep everything separated)
  • Make sure ‘gradle clean’ also cleans the generated files
  • Support gradle incremental builds
  • Making sure it compiles: the generated classes should be available in src/main/java, and execute the generate task before build/compile
  • BONUS: IntelliJ should generate the files automatically when you import the project or sync the project.

A big thanks to my colleague Willem Cheizoo from JDriven for helping me create this list and pointing me in the right direction.

Creating a generate task

To be able to use the codegen in our gradle task, we need to add the dependency to the buildscript in our build.gradle file.

Continue Reading

Forcing HTTPS with an .htaccess file on Heroku

The usual way

Normally, forcing HTTPS with an .htaccess file is pretty straightforward, and not too difficult. You simply add the following to the top of your .htaccess file:

You have a RewriteCond that checks whether HTTPS is on or off, and after that you create a RewriteRule that redirects the user to the same host/URI, but with HTTPS instead of HTTP. The L flag prevents any other rule in the .htaccess file from being applied, and the R flag is a redirect (the 301 status code is for SEO optimization).

See this for documentation on rewrite module for Apache server.

Why is it not working on Heroku?

So when you try this on an application hosted on Heroku (I’m using a Cedar stack), this won’t work because there will be a infinite redirect loop.

Continue Reading

Promise me you won’t use Promise.race

Before we start, if you’re not sure what JavaScript Promises are, read this post. It’s a really great introduction for Promises. Furthermore, the code examples in this post uses Arrow functions, if you are unfamiliar with them, check out this link for an explanation.

Introduction

My colleague, Erik Timmers, and I often have discussions about programming and related technologies. This blog post is the result of one of those discussions. We discovered that the function Promise.race didn’t exactly do what we expected. So we tested it, figured out how it worked, found out what we thought was wrong, and finally created a version of the Promise.race function that does what we expected. After that we went a little bit further…and added some functionality to the function. Please note that this code shouldn’t be used in production, or at the very least, it should be tested a bit more. We did it “because we could”, but also because we wanted to understand the functionality. If you would like to view, extend, learn from the actual code, the source code is also available on GitHub.

So what’s wrong with Promise.race?

So you’re working on a JavaScript application, and your IntelliJ (because why would you use any other IDE?) autocomplete pops up with the function ‘race’ when you write ‘Promise.’. So without looking at the documentation, what would you expect Promise.race to do?
My first though was, that you can probably pass a few promises to this function and it returns the value of the first promise that resolved. Makes sense right?

Continue Reading