DEV Community: Petros Stergioulas

'Code First' API Documentation with Springdoc and Spring Boot

Petros Stergioulas — Sat, 06 Jun 2020 08:49:20 +0000

This article was first published on reflectoring.io

When following a "code first" approach in API development, we first start with writing code, and then we generate the API specification from the code, which then becomes the documentation.

"Code first" is not the only way to develop an API. "API first" is another option where we do exactly the opposite. First, we write the specification, and then we generate code from that specification and implement against it.

Let's discuss the benefits of using this approach and how to implement it with Springdoc and Spring Boot.

thombergs / code-examples

A collection of code examples from blog posts etc.

When to Choose the "Code First" Approach

When we need to go to production fast, or create a prototype something, "code first" may be a good approach. Then we can generate our documentation from the API we have already programmed.

Another benefit of code first is the fact that the documentation will be generated from the actual code, which means that we don't have to manually keep the documentation in sync with our code. The documentation is more likely to match the behavior of the code and is always up-to-date.

Example Application

In this article, we'll be using Spring Boot together with springdoc-openapi.

All the annotations that we will be using are from Swagger. Springdoc wraps Swagger and offers us a single dependency which we can use to create our API documentation.

Getting Started

To get started we only need to add the Springdoc dependency (Gradle notation):

implementation 'org.springdoc:springdoc-openapi-ui:1.3.3'

First, let's define the path of our documentation. We define it in the application.yml of our Spring Boot project:

springdoc:
  api-docs:
    path: /reflectoring-openapi

Springdoc will now add the endpoint /reflectoring-openapi to our application where it will beautifully display our endpoints. For more configuration properties please check the official documentation.

Defining General API Information

Next, let's define some information about our API:

@OpenAPIDefinition(
  info = @Info(
  title = "Code-First Approach (reflectoring.io)",
  description = "" +
    "Lorem ipsum dolor ...",
  contact = @Contact(
    name = "Reflectoring", 
    url = "https://reflectoring.io", 
    email = "petros.stergioulas94@gmail.com"
  ),
  license = @License(
    name = "MIT Licence", 
    url = "https://github.com/thombergs/code-examples/blob/master/LICENSE")),
  servers = @Server(url = "http://localhost:8080")
)
class OpenAPIConfiguration {
}

Note that we don't need to define the class above as a Spring bean. Springdoc will just use reflection to obtain the information it needs.

Now, if we start the Spring Boot application and navigate to http://localhost:8080/swagger-ui/index.html?configUrl=/reflectoring-openapi/swagger-config, we should see the information we defined above:

Defining the REST API

Next, let's add some REST endpoints. We'll be building a TODO API with CRUD operations.

@RequestMapping("/api/todos")
@Tag(name = "Todo API", description = "euismod in pellentesque ...")
interface TodoApi {

  @GetMapping
  @ResponseStatus(code = HttpStatus.OK)
  List<Todo> findAll();

  @GetMapping("/{id}")
  @ResponseStatus(code = HttpStatus.OK)
  Todo findById(@PathVariable String id);

  @PostMapping
  @ResponseStatus(code = HttpStatus.CREATED)
  Todo save(@RequestBody Todo todo);

  @PutMapping("/{id}")
  @ResponseStatus(code = HttpStatus.OK)
  Todo update(@PathVariable String id, @RequestBody Todo todo);

  @DeleteMapping("/{id}")
  @ResponseStatus(code = HttpStatus.NO_CONTENT)
  void delete(@PathVariable String id);
}

With the @Tag annotation, we add some additional information to the API.

Now, we have to implement this interface and annotate our controller with
@RestController. This will let Springdoc know that this is a controller and that it should produce a documentation for it:

@RestController
class TodoController implements TodoApi {
  // method implementations  
}

Let's start the application again and take a look at the Swagger UI. It should look something like this:

Springdoc did its magic and created a documentation for our API!

Let's dive a little more into Springdoc by defining a security scheme.

Defining a Security Scheme

To define a security scheme for our application we just need to add the @SecurityScheme annotation in one of our classes:

// other annotations omitted
@SecurityScheme(
  name = "api", 
  scheme = "basic",
  type = SecuritySchemeType.HTTP,
  in = SecuritySchemeIn.HEADER)
class OpenAPIConfiguration {
}

The above @SecurityScheme will be referred to as api and will do a basic authentication via HTTP. We add this annotation in the OpenAPIConfiguration class.

Let's see what this annotation produced for us:

Our documentation has now also an "Authorize" Button! If we press this button we will get a dialog where we can authenticate:

To define that an API endpoint uses the above security scheme we have to annotate it with the @SecurityRequirement annotation.

Now, the TodoApi looks like this:

@RequestMapping("/api/todos")
@Tag(name = "Todo API", description = "euismod in pellentesque ...")
@SecurityRequirement(name = "api")
interface TodoApi {
    // other methods omitted
}

Now, the Swagger UI will show a lock on each of our endpoints to mark them as "secured":

Actually, the endpoints are not secured, yet. If we try to request the /api/todos resource, for example, we will still be able to receive the data without authentication:

We have to implement the actual security ourselves. See the code in the repository for the full implementation with Spring Security.

After securing the application we can now see that we receive a 401 status code if we try to access any resource under /api/todos.

After authenticating we can again access the resource:

Conclusion

As we saw in this article, the "code first" approach with Springdoc is all about speed. First, we build our API in code, then we generate the specification/documentation via annotations.
Springdoc elevates Swagger and helps us create our OpenAPI Specification.

If you want to have a deeper look, browse the code on GitHub.

API-First Development with Spring Boot and Swagger

Petros Stergioulas — Sat, 14 Mar 2020 19:39:25 +0000

This article was first published on reflectoring.io

Following an API-first approach, we specify an API before we start coding. Via API description languages, teams can collaborate without having implemented anything, yet.

Those description languages specify endpoints, security schemas, object schemas, and much more. Moreover, most of the time we can also generate code such a specification.

Often, an API specification also becomes the documentation of the API.

thombergs / code-examples

A collection of code examples from blog posts etc.

Benefits of API-First

To start working on an integration between components or systems, a team needs a contract. In our case, the contract is the API specification. API-first helps teams to communicate with each other, without implementing a thing. It also enables teams to work in parallel.

Where the API-first approach shines is on building a better API. Focusing on the functionality that it is needed to provide and only that. Minimalistic APIs mean less code to maintain.

Creating an API Spec with the Swagger Editor

Let's create our own OpenAPI specification in a YAML document. To make it easier to follow, we'll split the discussion into separate parts of the YAML document we're creating.

If you want to learn more details about the OpenAPI-Specification you can visit the Github repository.

General Information

We start with some general information about our API at the top of our document:

openapi: 3.0.2
info:
  title: Reflectoring
  description: "Tutorials on Spring Boot and Java."
  termsOfService: http://swagger.io/terms/
  contact:
    email: petros.stergioulas94@gmail.com
  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
  version: 0.0.1-SNAPSHOT
externalDocs:
  description: Find out more about Reflectoring
  url: https://reflectoring.io/about/
servers:
- url: https://reflectoring.swagger.io/v2

The openapi field allows us to define the version of the OpenAPI spec that our document follows.

Within the info section, we add some information about our API. The fields should be pretty self-explanatory.

Finally, in the servers section, we provide a list of servers that implement the API.

Paths

Next, we'll describe some paths. A path holds information about an individual endpoint and its operations:

paths:
  /user/{username}:
    get:
      tags:
      - user
      summary: Get user by user name
      operationId: getUserByName
      parameters:
      - name: username
        in: path
        description: 'The name that needs to be fetched. '
        required: true
        schema:
          type: string
      responses:
        200:
          description: successful operation
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        404:
          description: User not found
          content: {}

The $ref field allows us to refer to objects in a self-defined schema. In this case we refer to the User schema object (see the next section about Components).

The summary is a short description of what the operation does.

With the operationId, we can define a unique identifier for the operation. We can think about it as our method name.

Finally, the responses object allows us to define the outcomes of an operation. We must define at least one successful response code for any operation call.

Components

The objects of the API are all described in the components section. The objects defined within the components object will not affect the API unless they are explicitly referenced from properties outside the components object, as we have seen above:

components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: integer
          format: int64
        username:
          type: string
        firstName:
          type: string
        ... more attributes
        userStatus:
          type: integer
          description: User Status
          format: int32
  securitySchemes:
    reflectoring_auth:
      type: oauth2
      flows:
        implicit:
          authorizationUrl: http://reflectoring.swagger.io/oauth/dialog
          scopes:
            write:users: modify users
            read:users: read users
    api_key:
      type: apiKey
      name: api_key
      in: header

The schemas section allows us to define the objects we want to use in our API.

In the securitySchemes section, we can define security schemes that can be used by the operations.

There two possible ways to make use of security schemes.

First, we can add a security scheme to a specific operation using the security field:

paths:
  /user/{username}:
    get:
      tags:
      - user
      summary: Get user by user name
      security: 
        - api_key: []

In the above example we explicitly specify that the path /user/{username} is secured with the api_key scheme we defined above.

However, if we want to apply security on the whole project, we just need to specify it as a top-level field:

paths:
  /user/{username}:
    get:
      tags:
      - user
      summary: Get user by user name
security: 
  - api_key: []

Now, all of our paths should be secured with the api_key scheme.

Generating Code From an API Specification

Having defined an API, we'll now create code from the YAML document above.

We'll take a look at two different approaches to generating the code:

using the Swagger Editor to generate code manually, and
using the OpenAPI Maven plugin to generate code from a Maven build.

Generating Code from Swagger Editor

Although this is an approach that I wouldn't take, let's talk about it and discuss why I think it's a bad idea.

Let's go over to Swagger Editor and paste our YAML file into it. Then, we select Generate Server from the menu and pick what kind of a server we'd like to generate (I went with "Spring").

So why is this a bad idea?

First, the code that was generated for me is using Java 7 and Spring Boot 1.5.22, both of which are quite outdated.

Second, if we make a change to the specification (and changes happen all the time), we'd have to copy-and-paste the files that were changed manually.

Generating Code with the OpenAPI Maven plugin

A better alternative is to generate the code from within a Maven build with the OpenAPI Maven plugin.

Let's take a look at the folder structure. I chose to use a multi-module maven project, where we have two projects:

app, an application that implements the API from our specification.
specification, whose only job is to provide the API Specification for our app.

The folder structure looks like this:

spring-boot-openapi
├── app
│   └── pom.xml
│   └── src
│       └── main
│           └── java
│               └── io.reflectoring
│                   └── OpenAPIConsumerApp.java
├── specification
│   └── pom.xml
│   └── src
│       └── resources
│           └── openapi.yml
└── pom.xml

For the sake of simplicity, we omit the test folders.

Our app is a simple Spring Boot project that we can automatically generate on start.spring.io, so let's focus on the pom.xml from the specification module, where we configure
the OpenAPI Maven plugin:

<plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <version>4.2.3</version>
    <executions>
        <execution>
            <goals>
                <goal>generate</goal>
            </goals>
            <configuration>
                <inputSpec>
                  ${project.basedir}/src/main/resources/openapi.yml
                </inputSpec>
                <generatorName>spring</generatorName>
                <apiPackage>io.reflectoring.api</apiPackage>
                <modelPackage>io.reflectoring.model</modelPackage>
                <supportingFilesToGenerate>
                  ApiUtil.java
                </supportingFilesToGenerate>
                <configOptions>
                    <delegatePattern>true</delegatePattern>
                </configOptions>
            </configuration>
        </execution>
    </executions>
</plugin>

You can see the full pom.xml file on GitHub.

For this tutorial, we're using the spring generator.

Simply running the command ./mvnw install will generate code that implements our OpenAPI specification!

Taking a look into the folder target/generated-sources/openapi/src/main/java/io/reflectoring/model, we find the code for the User model we defined in our YAML:

@javax.annotation.Generated(...)
public class User   {
  @JsonProperty("id")
  private Long id;

  @JsonProperty("username")
  private String username;

  @JsonProperty("firstName")
  private String firstName;

  // ... more properties

  @JsonProperty("userStatus")
  private Integer userStatus;

  // ... getters and setters

}

The generator does not only generate the models but also the endpoints. Let's take a quick look at what we generated:

public interface UserApiDelegate {

    default Optional<NativeWebRequest> getRequest() {
        return Optional.empty();
    }

    /**
     * POST /user : Create user
     * Create user functionality
     *
     * @param body Created user object (required)
     * @return successful operation (status code 200)
     * @see UserApi#createUser
     */
    default ResponseEntity<Void> createUser(User body) {
        return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);

    }
  // ... omit deleteUser, getUserByName and updateUser
}

Of course, the generator cannot generate our business logic for us, but it does generate interfaces like UserApiDelegate above for us to implement.

It also creates a UserApi interface which delegates calls to UserApiDelegate:

@Validated
@Api(value = "user", description = "the user API")
public interface UserApi {

    default UserApiDelegate getDelegate() {
        return new UserApiDelegate() {};
    }

    /**
     * POST /user : Create user
     * Create user functionality
     *
     * @param body Created user object (required)
     * @return successful operation (status code 200)
     */
    @ApiOperation(value = "Create user", 
      nickname = "createUser", 
      notes = "Create user functionality", 
      tags={ "user", })
    @ApiResponses(value = { 
        @ApiResponse(code = 200, message = "successful operation") })
    @RequestMapping(value = "/user",
        method = RequestMethod.POST)
    default ResponseEntity<Void> createUser(
      @ApiParam(value = "Created user object" ,required=true )  
      @Valid 
      @RequestBody User body) {
        return getDelegate().createUser(body);
    }

    // ... other methods omitted
}

The generator also creates a Spring controller for us that implements the UserApi interface:

@javax.annotation.Generated(...)
@Controller
@RequestMapping("${openapi.reflectoring.base-path:/v2}")
public class UserApiController implements UserApi {

    private final UserApiDelegate delegate;

    public UserApiController(
      @Autowired(required = false) UserApiDelegate delegate) {
        this.delegate = Optional.ofNullable(delegate)
            .orElse(new UserApiDelegate() {});
    }

    @Override
    public UserApiDelegate getDelegate() {
        return delegate;
    }
}

Spring will inject our implementation of UserApiDelegate into the controller's constructor if it finds it in the application context. Otherwise, the default implementation will be used.

Let's start our application and hit the GET endpoint /v2/user/{username}.

curl -I http://localhost:8080/v2/user/Petros
HTTP/1.1 501
Content-Length: 0

But why do we get a 501 response (Not Implemented)?

Because we did not implement the UserApiDelegate interface and the UserApiController used the default one, which returns HttpStatus.NOT_IMPLEMENTED.

Now let's implement the UserApiDelegate:

@Service
public class UserApiDelegateImpl implements UserApiDelegate {

    @Override
    public ResponseEntity<User> getUserByName(String username) {
        User user = new User();
        user.setId(123L);
        user.setFirstName("Petros");

        // ... omit other initialization

        return ResponseEntity.ok(user);
    }
}

It's important to add a @Service or @Component annotation to the class so that Spring can pick it up and inject it into the UserApiController.

If we run curl http://localhost:8080/v2/user/Petros again now, we'll receive a valid JSON response:

{
  "id": 123,
  "firstName": "Petros",
  // ... omit other properties
}

The UserApiDelegate is the single point of truth. That enables us to make fast changes in our API. For example, if we change the specification and generate it again, we only have to implement the newly generated methods.

The good thing is that if we won't implement them, our application doesn't break. By default, those endpoints would return HTTP status 501 (Not Implemented).

In my opinion, generating the OpenAPI Specification with Maven plugin instead of Swagger Editor is the better choice.
That's because we have more control over our options. The plugin provides some configuration and with Git as a version control tool, we can safely track any changes in either pom.xml and openapi.yml.

Conclusion

With OpenAPI we can create an API specification that we can share among teams to communicate contracts. The OpenAPI Maven plugin allows us to generate boilerplate code for Spring Boot from such a specification so that we only need to implement the business logic ourselves.

You can browse the example code on GitHub.

Microservices: OAuth2 vs Simple JWT Authentication

Petros Stergioulas — Tue, 17 Dec 2019 12:44:12 +0000

I am trying to figure out, how I should implement the security for my microservices architecture.

For example, I have a client(web), a gateway and some other microservices.

Now I am thinking, should I implement my own Authentication/Authorization server(not an OAuth2), which will just authenticate the user? Or should I just pick a standard like keycloak or uaa?

Does it make sense to use a fully OAuth2 capable server?

Hey Cyber Security Experts, I have some questions!

Petros Stergioulas — Tue, 19 Nov 2019 18:00:07 +0000

I am thinking of expanding my knowledge on the field. Based on that thought, I am considering doing a Master.

What should one know, to be able to work on the field? Do you think a Master is a waste of resources(money, time, etc)?

Currently I am a developer, will that help me on that journey?

Thank you!

Getting started with Spring WebFlux and R2DBC in Spring Boot

Petros Stergioulas — Fri, 01 Nov 2019 17:04:35 +0000

Introduction

In this short article I will try to introduce you to R2DBC using Spring Data R2DBC and in the world of reactive applications with Spring WebFlux.

What is R2DBC and why should you bother looking at it? First, R2DBC stands for Reactive Relational Database Connectivity. What does that mean? In simple words, R2DBC brings the possibility of non-blocking calls to our Relational Databases (SQL)!

Quoting https://r2dbc.io/, R2DBC is in a nutshell:

Reactive Streams - R2DBC is founded on Reactive Streams providing a fully reactive non-blocking API.
Relational Databases - R2DBC engages SQL databases with a reactive API, something not possible with the blocking nature of JDBC.
Scalable Solutions - Reactive Streams makes it possible to move from the classic one thread per connection approach to a more powerful, more scalable approach.
Open Specification - R2DBC is an open specification establishing a SPI that driver vendors can implement and clients can consume.

In this tutorial, we will build a simple REST API with Kotlin, Spring WebFlux and we will connect to our H2 Database using Spring Data R2DBC.

Getting Started

If you want to easily get started with a Springboot project I recommend always using the Spring Initializr.

The Second Best Place on the Internet @ Josh Long.

Gradle Configuration

First of all, we have to configure our build.gradle.kts and include the dependencies:

For the complete build.gradle.kts check here:
build.gradle.kts.

Application Configuration

Spring Boot comes with a handful of auto-configurations for Spring Data R2DBC out-of-the-box.
Below we are leveraging the power of Spring Boot to create a connection to the database:

Then we create a table called Employee and we populate it with some data:

While that may not seem really safe, in our application we do not have any problems, while the database will always be created on startup and destroyed on shutdown of the application.

REST API

Ok, so we created our database and we populated it with data, now what? Let's make use of it and create a REST API!

Below we have a simple domain model called Employee.

Then, let's create our repository, which will provide some queries out-of-the-box and we will also define one of our own.

Last but not least, let's create our endpoint:

Result

Let's execute our application with the command ./gradlew bootRun.

The application now runs on http://localhost:8080!! Congratulations!

Closing thoughts

Spring Data R2DBC is still on experimental stage. Although it is on the official release of Spring Boot 2.2.0, I would not recommend using it on production :).

I hope you now have a better understanding of R2DBC.

You can find the repository right here:

Petros0 / spring-boot-r2dbc-kotlin

Spring Boot R2DBC

This project aims to give an idea on how to work with the R2DBC and Spring Data R2DBC.

Getting Started

./gradlew bootRun, the application now runs localhost:8080.

Navigate to:

http://localhost:8080/employees/

Available endpoints:

GET http://localhost:8080/employees/

GET http://localhost:8080/employees/1

POST http://localhost:8080/employees/

DELETE http://localhost:8080/employees/

View on GitHub

Resources

Getting started with RSocket in Spring Boot

Petros Stergioulas — Mon, 10 Jun 2019 14:21:29 +0000

Introduction

RSocket is a binary protocol for use on byte stream transports such as TCP, WebSockets, and Aeron.

It enables the following symmetric interaction models via async message passing over a single connection:

request/response (stream of 1)
request/stream (finite stream of many)
fire-and-forget (no response)
event subscription (infinite stream of many)

It supports session resumption, to allow resuming long-lived streams across different transport connections. This is particularly useful for mobile⬄server communication when network connections drop, switch, and reconnect frequently.

In our tutorial, we will implement RSocket using the Java programming language.

Why Springboot

Although I could simply implement RSocket with a simple Java application, I chose Springboot because it's a huge project on the JVM languages ecosystem. Springboot doesn't have a stable version for RSocket yet, but that shouldn't stop us experimenting with it.

Structure

Our project will consist of two sub-projects. The Consumer, who will do the requests and the Producer, who will provide the Consumer with data.

Getting Started

If you want to easily get started with a Springboot project I recommend always using the Spring Initializr.

Configuring Gradle

First of all we have to configure our build.gradle and include the rsocket-starter-dependency from Springboot:

For the Consumer we should include also the reactive-web-starter dependency, because we want to somehow display the data that we receive from the Producer.

Configuration

Now let's get our hands dirty and write some code 😉.

Producer

First we have to configure in which port will our Producer receive new connections:

The spring.rsocket.server.port=7000 configures the RSocket to start listening on port 7000 and the spring.main.lazy-initialization=true is to make sure that Springboot will initialize its beans lazily.

Consumer

Now, here, we configure the RSocket client, by creating two Beans of type RSocket and RSocketRequester. The RSocket bean is used to create the connection to the Producer. The RSocketRequester bean is like our WebClient (if we are using Reactive) or the RestTemplate (if we are using MVC), he will do the requests to Producer.

The Actual Code

Our two applications (the Producer and the Consumer) will use the following domain objects for their communication:

Simple Communication

Let's start with an easy example, a simple Request with a single Response.

Producer

If you ever used WebSockets with Springboot the @MessageMapping annotation should be familiar.
Here, with the @MessageMapping("greet") we specify the route "greet", which receives a GreetingsRequest and returns a single object GreetingsResponse as a response.

Consumer

Here we see a simple @RestController which injects the RSocketRequester (the one we configured earlier) and uses him to do the Request. As you see, we tell the requester to do a Request to the "greet" route (which we configured earlier in the Producer).

Communication with Stream

Delivering a stream of data with RSocket comes natural and with not that much of an effort.

Producer

As you see in the gist above, we configured our @MessageMapping as before, but now we return a Flux (don't know what Mono and Flux are? Check this StackOverflow post).

We also use the .delayElements() method to simulate a delay between our responses.

Consumer

Not much have changed from our other request to the Producer, clearly the .route("greet-stream"). But if you see carefully, now our @GetMapping produces a text/event-stream and not the default application/json.

Let's check the result!

Closing thoughts

So, that was it! I hope I gave you a clear explanation on how to use the new RSocket protocol!

You can find the project here:

Petros0 / springboot-rsocket

Springboot RSocket

This project aims to give an idea on how to work with the RSocket protocol with the Springboot framework.

Getting started

./gradlew :producer:bootRun

./gradlew :consumer:bootRun

Navigate to:

http://localhost:8080/greet/{YourName}

http://localhost:8080/greet-stream/{YourName}

For more, check my getting started guide here: https://dev.to/petros0/getting-started-with-rsocket-in-springboot-5889.

View on GitHub

Thanks for reading and have fun!

Resources

I wanna start learning about Machine Learning. From where should I start?

Petros Stergioulas — Sun, 14 Oct 2018 14:57:04 +0000

DEV Community: Petros Stergioulas

'Code First' API Documentation with Springdoc and Spring Boot

thombergs / code-examples

A collection of code examples from blog posts etc.

When to Choose the "Code First" Approach

Example Application

Getting Started

Defining General API Information

Defining the REST API

Defining a Security Scheme

Conclusion

API-First Development with Spring Boot and Swagger

thombergs / code-examples

A collection of code examples from blog posts etc.

Benefits of API-First

Creating an API Spec with the Swagger Editor

General Information

Tags

Paths

Components

Generating Code From an API Specification

Generating Code from Swagger Editor

Generating Code with the OpenAPI Maven plugin

Conclusion

Microservices: OAuth2 vs Simple JWT Authentication

Hey Cyber Security Experts, I have some questions!

Getting started with Spring WebFlux and R2DBC in Spring Boot

Introduction

Getting Started

Gradle Configuration

Application Configuration

REST API

Result

Closing thoughts

Petros0 / spring-boot-r2dbc-kotlin

Spring Boot R2DBC

Getting Started

Resources

Getting started with RSocket in Spring Boot

Introduction

Why Springboot

Structure

Getting Started

Configuring Gradle

Configuration

Producer

Consumer

The Actual Code

Simple Communication

Producer

Consumer

Communication with Stream

Producer

Consumer

Closing thoughts

Petros0 / springboot-rsocket

Springboot RSocket

Getting started

Resources

I wanna start learning about Machine Learning. From where should I start?