Here you will find examples demonstrating Vert.x Apex in action.
Apex is a tool-kit for writing web applications with Vert.x. Please consult the Apex manual for detailed documentation on Apex.
When running in an IDE you can edit src/main/resources/vertx-default-jul-logging.properties to configure logging.
Trace logging is enabled for Apex classes so you can easily trace requests as they are routed through different
handlers.
To use Apex in your own Maven or Gradle project you will need following dependencies
Group ID: io.vertx Artifact ID: vertx-core
and
Group ID: io.vertx Artifact ID: vertx-apex
If you’re using auth in your Apex application you will also need the dependency:
Group ID: io.vertx Artifact ID: vertx-auth
If you’re using a template engine you will also need to add the engine dependency explicitly, depending on the engine you are using.
The traditional hello world example. This one creates a server which just responds with "Hello World! to each request.
Apex is a great fit for HTTP/REST microservices.
Here’s a simple micro-service example which implements an API for a product catalogue.
The API allows you to list all products, retrieve details for a particular product and to add a new product.
Product information is provided in JSON.
- List all products
-
GET /products
- Get a product
-
GET /products/<product_id>
- Add a product
-
PUT /products/<product_id>
Run the server either in your IDE or on the command line, then open your browser and hit list products to start playing with the API.
This example shows a simple web-site containing some static pages and also a page dynamically generated using templates.
The dynamic page outputs some information (path and headers) of the request. It uses the MVEL template engine but you could use any of the other template engines if you prefer.
Run the server either in your IDE or on the command line, then open your browser and hit link:http://localhost:8080 and click on the links
This example shows how to use sessions with Apex. Sessions are available between requests and last the length of the browser session.
The example increments a counter in the session every time a request hits the server.
Run the server either in your IDE or on the command line, then open your browser and hit link:http://localhost:8080 then refresh the page a few times - you should see the hit count increase.
|
Note
|
Depending on your browser you may see it increase by two each time you refresh! Why is that? Some browsers will actually send two HTTP requests every time you refresh - one to request the favicon for the site and one to request the actual page. |
This example demonstrates a full duplex connection between the browser and the server side.
The connection remains open so you can communicate easily between server and browser or server and browser by just sending messages over the event bus, like you would on the server side.
It uses the SockJS event bus bridge to effectively extend the Vert.x event bus to the client side so you can interact with server side event bus services from client side JavaScript. SocksJS gives a WebSocket-like API in client side JavaScript even if the browser or network doesn’t support WebSockets.
This is ideal for so-called real-time web applications where you want quick, responsive communication between server and client and you’re probably rendering the user interface on the client side.
Run the server either in your IDE or on the command line, then open your browser and hit link:http://localhost:8080
This serves the index page which contains some JavaScript which opens an event bus connection to the server.
When the connection is open, a handler is registered on the event bus against the address news-feed. When data
arrives in the handler the script just uses some simple JQuery to write the message to the page.
On the server side, in the server we set a periodic
timer that fires every second and sends a message to the news-feed address.
When you get the index page in your browser you should see it update every second as it receives a message.
This example demonstrates 2-way communication between the client and the server using the event bus bridge and web sockets.
The index.html file bootstraps the vertxbus.js bridge from the client and uses jQuery to handle manipulating the DOM and registering event handlers.
When you load the index page in a browser, you should see a div for chat messages and an input field where you can enter your own messages. Typing in the input field and pressing ENTER will cause the input to be sent via the event bus to the server. The server will accept the message, prepend it with a timestamp and publish back to all registered listeners (e.g. All connected clients). Take note of the addInboundPermitted and addOutboundPermitted settings on the BridgeOptions object to be sure that you authorize the correct messages to traverse the event bus bridge in the appropriate direction.
To run the example, run Server.java in your IDE by right clicking, or at the command line, and point your browser
at link:http://localhost:8080
This example shows a basic static web-site that contains both public pages and pages that are only accessible to a logged in user.
Requests to paths starting with /private/ will require login.
The example uses a simple auth service which gets user/password/role information from a properties file
src/main/resources/vertx-users.properties.
The type of login used here is redirect login. If a request is made to a private resource and the session isn’t already logged in a redirect will be sent to the browser causing it to load the login page. When the login form is submitted it is handled by the form login handler which then redirects the browser back to the originally requested resource if login was successful.
Run the server either in your IDE or on the command line, then open your browser and hit link:http://localhost:8080 and click around the links