DEV Community: Lorna Jane Mitchell

Get to know the Aiven API with Postman

Lorna Jane Mitchell — Tue, 22 Nov 2022 16:54:00 +0000

Choosing cloud providers with APIs is a smart move; having an API available means you can build any additional integrations that your application requires, in addition to what's provided as standard. The downside is getting to know someone else's API, which can be a slow and painful process if good developer resources aren't available.

At Aiven we'd love you to get to know our API, so we created a Postman collection to help you get started. If you haven't used Postman, it's a friendly interface for humans to work with APIs. We use it ourselves, so we created something you could use too. In this post, you'll use Postman to take your first steps with the Aiven API.

Before you start

You can use Postman either in your web browser or as a desktop application. Whichever you choose, sign up for a free account, or sign in if you have one already.

Navigate to the collection. To get your own copy of the collection to work with, right-click on the collection and choose "Create a fork".

You're prompted to give the collection a name, and which workspace to move it to. "My workspace" is a good choice if you're not sure.

Get your head in the clouds

The first API call we'll make is simple: ask the Aiven API for a list of all the clouds that a user can deploy their services to on Aiven.

Expand your collection in the left-hand bar and click on "Clouds". The request you want is called "List available cloud platforms", and it doesn't need any editing or changes. Go ahead and click the "Send" button over on the right-hand side.

Well done - you've made your first API call! The results display in the lower half of the screen; Postman autodetects that the response is in JSON, and format it nicely so that us mere mortals can read it. Have a scroll down and pick a location that sounds like a fun place to host your database.

This is fun, but it'll be more fun when you're working with your own databases in the cloud, so the next step is to identify yourself to the API when you make a request.

Send credentials with your API request

When you sign in to a website, you probably use a username and password (Aiven also supports SSO and allows you to add 2FA, in case you're interested). For APIs, we usually use an authentication token. This is good practice because you can create a new token for each application; those credentials can each be independently rotated or revoked without affecting any other applications - because they each use their own tokens.

If you don't already have an Aiven account, sign up for a free trial.
Visit your Aiven profile page and scroll down to "Authentication tokens" to create a new token.
Enter a description so that you will know which token this is, and set the expiry in hours for your token (leave it blank for a token that does not expire). Click "Generate token".
Copy the token, ready to set it in the Postman collection.
Back in Postman, click the collection menu, and go to "Edit". On the "Variables" tab, paste your token value in under "Current value" for the "authToken" variable. Press the "Save" button on the right-hand side above the tabs.

All the requests in the collection are set up to use this variable, so by setting it here, it's used for all the API calls. Speaking of which, shall we make another one?

Create a cloud database

Aiven offers a variety of different databases and other data things, like Apache Kafka (technically not a database) and Grafana (definitely not a database), and we call them all "services".

In the "Services" folder within the collection, select the request called "Create a service". You can create whichever service type you like, but the example values create a Redis, which is a great place to start.

Under the "Params" section, update the path variable project with a project name that exists in your account that you want to use.
This is a POST request, so most of the interesting parts are in the body data; this can be found on the "Body" tab of the request. Have a look at the data, you might like to set a nicer value for service_name, for example.

When you are happy with the values, click "Send". The response should have status 200 and show information about your new service.

The right status code and some JSON is a good outcome, but it's not very exciting, is it? Head back to your Aiven console and you should see a new Redis service.

A whole new Redis to play with! If you click on the service, you'll see an overview page for the service including lots of configuration and the connection information to use it. Check out our docs on connecting to Redis using the redis_cli tool.

Power off the services when you don't need them

One big concern about working with cloud services is how easy it is to start services that then hang around, running up the bills. So, once you've finished playing with your cloud Redis service, let's remove it. It's only a Postman call to get it back, after all.

Look in the "Services" folder of the collection again, and this time select "Delete a service".

On the "Params" tab, enter both the project and service name that you used. Send the request - and again we're looking for a response status of 200 OK.

Check back on your Aiven services list: as if by magic, your service is gone.

Tip: You can also use the "Update service configuration" request and set the powered value to true or false to power off your services when you're not using them. This is especially handy for development platforms that only need to run while you are working, which is hopefully not all hours of the day. Please note that this fully removes the service, and powering it on restores it from a backup. This can cause settings to reset.

Postman, Aiven and APIs

Whether you use Postman for your day-to-day tasks, or use it as an excellent way to get to know a new API, the Aiven Postman collection gives you a way to get started quickly.

Learn more about our API by checking out a detailed blog post about using Aiven's API from cURL and Postman, and the Aiven API reference docs.

The Postman collection has just a handful of endpoints. Tell us what we should add there next! And let us know what you build, we love to see it (and we accept guest blog posts if it's something really cool).

Add Aiven database magic to your Laravel project

Lorna Jane Mitchell — Mon, 01 Nov 2021 11:37:05 +0000

Our mission at Aiven is to make developers' lives better. Today I'd like to share our new tool that makes Laravel developers' lives better by adding some helpful functionality to their projects.

Laravel is the most popular PHP framework in use today, and is usually backed by either MySQL or PostgreSQL databases (Aiven offers both). Many developer platforms use one database for development and another for specific sets of test data. You might also need to connect elsewhere to debug a specific problem. However, switching between databases can be cumbersome.

Luckily we have a solution for you! The aiven-laravel package makes it painless to reconfigure your database connection. It adds commands to the artisan command line utility that you can use to configure your application to point to any of your Aiven database services. It also adds some helpers to power off any databases that are not in use, so you can save that money for a more productive purpose.

Set up the Aiven-Laravel package

If you're new to Aiven, you can sign up for a free trial to get started. If you're new to Laravel, it has a nice starter project you can use to begin.

Add aiven-laravel to your existing (or newly created) project with Composer; the project page has the full installation instructions. You will need to generate an Aiven access token to connect your Aiven account, and then you are ready to Aiven your Laravel ... (is Aiven a verb? It is now).

Configure Laravel to use an Aiven service

aiven-laravel makes setting the configuration easier whether you're running MySQL or PostgreSQL on Aiven (or indeed Redis or OpenSearch, which are also common and sound combinations for Laravel). The default configuration for Laravel is to use a .env file and to list the database host, port, and other details separately. However, it also supports use of the DATABASE_URL environment variable to hold an entire connection string. This can be a more convenient way to work with database connections. Set the single string in your .env file for development, and configure just one environment variable on the cloud platform you deploy to.

To check the databases and their types that are currently in your Aiven account, use this command:

php artisan aiven:list

Note: If you installed the aiven/aiven-laravel package without reading the instructions and didn't configure it yet, it will prompt you with the environment variables you need to set. Because, yes, this package was built by an engineer who doesn't read setup instructions either.

Let's say you have a MySQL service called dev-db. You can get the configuration that you need to connect to it from Laravel with:

php artisan aiven:getconfig --service dev-db

Take the output of the command and put it wherever you need your config to go! If you're developing locally, this is .env by default, but if you use multiple environment config files or are managing your environment differently, you can use these values there instead.

Avoid cloud bill surprises

One thing that stops people from modernizing their setup and moving to the cloud, especially for development, is how easy it is to accidentally misconfigure something and get a large bill. It happens too often, and it's definitely something that all developers should be cautious of. Aiven's pricing includes data transfer so the price shown is what you'll pay if you leave the database running full time - this by itself reduces the risks hugely.

Another way to keep costs under control is to turn things off when you are not using them, and this applies particularly to development platforms. Aiven gives the ability to power off your database when you're not using it, and power it back on unchanged - and we've added support to do that from artisan with the Aiven-Laravel package.

When you sit down to do some development work and need your database:

php artisan aiven:powerup --service dev-db

[your amazing things happen here]

When you have finished for the day, stop the meter from running by powering the service down again until next time:

php artisan aiven:powerdown --service dev-db

For databases that don't need to be always on, the test platforms for a client that you don't need to use every day ... this approach makes the cloud a very attractive place to keep your databases for low-friction access when you need them.

Aiven-Laravel and you

The Aiven-Laravel package is a new release, we know that plenty of PHP developers use our platform already, and we would love to hear from you if you find the tool useful (or not!). What would you add? Is there anyone you think should try out the tool? Issues, stars and pull requests are more than welcome on the GitHub repository, we're excited!

M3 for Metrics

Lorna Jane Mitchell — Tue, 17 Aug 2021 11:45:51 +0000

One key use case for Aiven for M3 is for handling the monitoring data from other systems. In this post you will do just that, by setting up a PostgreSQL service and collecting metrics from it using M3. To finish the picture, Grafana will be used to inspect the data you collect.

Start with something to monitor

To begin with, you need a PostgreSQL service. It doesn't matter what you choose here since this service isn't going to do any important work, it's merely an exhibition piece to collect metrics from (sorry, PostgreSQL!).

With a PostgreSQL service running, you can start to collect metrics from it.

Collect metrics with Aiven for M3

From the PostgreSQL service overview page, configure the metrics integration with a new M3 service:

Choose Manage integrations.
Locate the one named "Send service metrics to..." (not the one for receiving), and choose Use integration.
When prompted, create a new M3DB service, and configure it to your liking. To minimize latency, I usually use the same cloud region as the thing I'm monitoring.

The metrics collected from PostgreSQL are now being sent to M3.

Visualize the data with Grafana

The next step is to add the dashboard integration so you can see the data you are collecting. From the M3 service overview page, let's set up a Grafana dashboard:

Choose Manage integrations.
Select Dashboard and then Use integration.
Choose a new Grafana service, and again, configure the service to suit your needs.

Once created, you can access Grafana by opening its Service URI in a new browser tab, and logging in with the user and password listed on the service overview page. To get you started, Aiven includes a default dashboard that shows some of the most common metrics.

To access the pre-built dashboard:

From the left hand menu, go to the Dashboards section (4 squares) and choose Manage
Click on the dashboard called "Aiven PostgreSQL - [database name] - Resources"

You now have a clear view of your PostgreSQL database health.

Click the dashboard settings, and choose "Save As" to use this dashboard as a template for your own that you can make changes to. The default one gets reset to its original state at intervals.

The list of PostgreSQL metrics exposed to Grafana gives more information about the fields that are available.

Integrations in action

The integrations are now in place, and you can see both the data coming and the dashboard integration from the M3 service overview page.

Following the same approach, you can add metrics integrations to all of your other Aiven services, and send data to the M3 database you created. You can also write metrics from non-Aiven services to M3 to bring all the data you need into one place, and to visualize it with Grafana.

A Developer's First Impression of M3DB

Lorna Jane Mitchell — Tue, 27 Jul 2021 21:05:48 +0000

One of the newest products on the Aiven platform is our M3 offering. As a distributed time series database it's ideal for storing the ever-growing number of data points that we collect in and about modern applications.

What immediately strikes me about M3 is how it is designed to fit in alongside the other tools in a likely architecture. It has interfaces to match the ones we already know and love from Prometheus and InfluxDB. The integration with Grafana is also seamless.

It's as if M3 is designed to painlessly upgrade a single component of our existing data platform.

M3 speaks Prometheus

Prometheus is commonly used for server monitoring. If your platform is already sending data to Prometheus, then changing the data store to M3 will be painless. A server agent such as Telegraf can send data to M3 via its Prometheus write endpoints just as easily as it sends data to Prometheus itself.

There's nothing shiny here, because the intentional reuse of protocols does not make good headlines. It does however make excellent integrations and successful migration projects, and I know which I prefer from the tools I choose!

As our platforms scale and grow, so do our monitoring data requirements. Since we outgrew our previous solution, Aiven now uses M3 in an observability setup. We think this platform could be very useful for other organisations on a similar journey.

M3 speaks InfluxDB

Whether you are replacing an existing InfluxDB for your time series data or metrics, or adopting M3 and making use of one of the existing tools that integrates with InfluxDB, M3 is here for you. The compatible wire protocol enables both seamless migrations of existing platforms and easy adoption of M3 as a time series database platform in a new application.

InfluxDB is a mature platform and there are several libraries and integrations available. Since those will also work for M3, the learning curve for pushing data into the application is pretty flat. I found this makes M3 with all its incredible features and scalability a surprisingly approachable offering.

Grafanical ease of integration

The thing about time series data is that there's rather a lot of it. That's even more true if you're building at a scale that needs M3. Luckily, the Aiven platform makes it very simple to link the M3 service with a Grafana dashboard using the Prometheus read API that M3 has. This brings your data into Grafana, alongside any other data sources that you're already using, and lets you start visualising what's going on in your application.

M3 builds on all these existing integrations and adds some magical scalability into the mix. This makes M3 a very exciting prospect for developers, and it's a platform I'll be building on again in future.

Not using Aiven services yet? Sign up now for your free trial at https://console.aiven.io/signup!

Identifying Time Series Data

Lorna Jane Mitchell — Fri, 16 Jul 2021 16:16:54 +0000

Start with something to monitor

Start with a PostgreSQL service. It doesn't matter what you choose here since this service isn't going to do any important work, it's merely an exhibition piece to collect metrics from (sorry, PostgreSQL!).

With a PostgreSQL service running, you can start to collect metrics from it.

Collect metrics with Aiven for M3

From the PostgreSQL service overview page, configure the metrics integration with a new M3 service:

Choose "Manage integrations"
Locate the one for sending metrics (not the receiving one), and chose "Use integration"
When prompted, create a new M3DB service, and configure it to your liking. I usually use the same cloud region as the thing I'm monitoring.

With PostgreSQL now having its metrics collected and sent to M3, your next step is to add the dashboard integration so you can see the data.

Visualize the data with Grafana

From the M3 service overview page, let's set up a Grafana dashboard:

Choose "Manage integrations"
Select "Dashboard" and then "Use integration"
Choose a new Grafana service, and again, configure the service to suit your needs.

Once created, you can access Grafana by opening its Service URI in a new browser tab, and logging in with the User and Password listed on the service overview page. To get you started, Aiven includes a default dashboard that shows some of the most common metrics.

To access the pre-built dashboard:

From the left hand menu, go to the Dashboards section (4 squares) and choose "Manage"
Click on the dashboard called "Aiven PostgreSQL - [database name] - Resources"

You now have a clear view of your PostgreSQL database health.

Click the dashboard settings and choose "Save As" to use this dashboard as a template for your own that you can make changes to. The default one gets reset to its original state at intervals.

Integrations in action

The integrations are now in place, and you can see both the data coming and the dashboard integration from the M3 service overview page.

Following the same approach, you can add metrics integrations to all of your other Aiven services and send data to the M3 database you created. You can also write metrics from non-Aiven services to M3 to bring all the data you need into one place, and to visualize it with Grafana.

Tips for Designing Apache Kafka Message Payloads

Lorna Jane Mitchell — Thu, 29 Apr 2021 09:42:21 +0000

Event-Driven systems are increasingly our future and that's one reason why so many developers are adding Apache Kafka to their tech stacks. Getting the different components in your systems talking nicely to one another relies on a rather mundane but crucial detail: a good data structure in the message payloads. This article will pick out some of the best advice we have for getting your Apache Kafka data payloads well designed from the very beginning of your project.

Use all the features of Apache Kafka records

The events that we stream with Kafka can support headers as well as keys and the main body of the payload. The most scalable systems use all these features appropriately.

Use the header for metadata about the payload, such as the OpenTelemetry trace IDs. It can also be useful to duplicate some of the fields from the payload itself, if they are used for routing or filtering the data. In secure systems, intermediate components may not have access to the whole payload, so putting the data in the header can expose just the appropriate fields there. Also consider that, for larger payloads, the overhead of deserializing can be non-trivial. Being able to access just a couple of fields while keeping the system moving can help performance, too.

The keys in Apache Kafka typically do get more attention than the headers, but we should still make sure we are using them as a force for good. When a producer sends data to Kafka, it specifies which topic it should be sent to. The key usually defines which partition is used. If the key isn't set, then the data will be spread evenly across the partitions using a round-robin approach. For a lot of unrelated events in a stream, this makes good use of your resources.

If the key you're using doesn't vary much, your events can get bunched into a small number of partitions (rather than spread out). When this happens, try adding more fields to give more granular partition routing. Keep in mind that the contents of each partition will be processed in order, so it still makes sense to keep logical groupings of data.

For example, consider a collection of imaginary factories where all the machines can send events. Mostly they send sensor_reading events, but they can also send alarm events, that are like a paper jam in the printer but on a factory scale! Using a key like this will give us a LOT of data on one partition:

{
    "type": "sensor_reading"
}

So we could add another field to the key for these readings, maybe to group them by factory location:

{
    "type": "sensor_reading",
    "factory_id": 44891
}

Combining the type and factory in the key ensures that records of the same event type and the same factory will be processed in the order they were received. When it comes to designing the payloads, thinking about these aspects early on in the implementation process can help avoid performance bottlenecks later.

Data structures: nested data or simple layout?

No matter how certain I am that this payload will only ever contain a collection of things, I always use an object structure rather than making the data an array at the top level. Sometimes, it just leaves a rather lonely fieldname with a collection to take care of. But when things change and I do need to add an extra field, this "one weird trick" makes me very grateful.

Make no mistake, it's not foresight. It's the scars of the first API I ever shipped having to move to v1.1 within a week of launch for precisely this reason. Learn from my mistakes!

In general, it's also helpful to group related fields together; once you get 30 fields in a payload and they are sorted alphabetically then you will wish you had done something differently! Here's an example showing what I mean:

  {
    "stores_request_id": 10004352789,
    "parent_order": {
      "order_ref": 777289,
      "agent": "Mr Thing (1185)"
    },
    "bom": [
      {"part": "hinge_cup_sg7", "quantity": 18},
      {"part": "worktop_kit_sm", "quantity": 1},
      {"part": "softcls_norm2", "quantity": 9}
  ]}

Using the parent_order object to keep the order ref, its responsible person, and any other related data together makes for an easily navigable structure, more so than having those fields scattered across the payload. It also avoids having to artificially group the fields using a prefix. Don't be afraid to introduce extra levels of data nesting to keep your data logically organised.

How much data to include is another tricky subject. With most Kafka platforms limiting payloads to 1MB, it's important to choose carefully. For text-based data, 1MB is quite a lot of information, especially if a binary format such as Avro or Protobuf is used (more on those in a moment). As a general rule of thumb, if you are trying to send a file in a Kafka payload, you are probably doing it wrong!

These design tradeoffs are nothing new and I rely mostly on the prior art in the API/webhooks space to inform my decisions. For example, hypermedia is the practice of including links to resources rather than the whole resource. Publishing messages that will cause every subscriber to make follow-on calls is a good way to create load problems for your server but hypermedia can be a useful middle ground, especially where the linked resources are cacheable.

Data Formats: JSON, Avro ... these are not real words

Wading through the jargon of data formats is a mission by itself, but I'd like to give some special mentions to my favourites!

JSON: Keep it simple JSON formats are very easy to understand, write, read and debug. They can use a JSON Schema to ensure they fulfil an expected data structure, but you can equally well go freeform for prototyping and iterating quickly. For small data payloads, I often start here and never travel any further. However, JSON is fairly large in size for the amount of data it transmits, and it also has a rather relaxed relationship with data types. In applications where either or both of these issues cause a problem, then I move on from JSON and choose something a bit more advanced.

Avro: Small and schema-driven Apache Avro is a serialisation system that keeps the data tidy and small, which is ideal for Kafka records. The data structure is described with a schema (example below) and messages can only be created if they conform with the requirements of the schema. The producer takes the data and the schema, produces a message that goes to the kafka broker, and registers the schema with a schema registry. The consumers do the same in reverse: take the message, ask the schema registry for the schema, and assemble the full data structure. Avro has a strong respect for data types, requires all payloads conform with the schema, and since data such as fieldnames is encoded in the schema rather than repeated in every payload, the overall payload size is reduced.

Here's an example Avro schema:

{
    "namespace": "io.aiven.example",
    "type": "record",
    "name": "MachineSensor",
    "fields": [
        {"name": "machine", "type": "string", "doc": "The machine whose sensor this is"},
        {"name": "sensor", "type": "string", "doc": "Which sensor was read"},
        {"name": "value", "type": "float", "doc": "Sensor reading"},
        {"name": "units", "type": "string", "doc": "Measurement units"}
    ]
}

There are other alternatives, notably Protocol Buffers, known as ProtoBuf. It achieves similar goals by generating code to use in your own application, making it available on fewer tech stacks. If it's available for yours, it's worth a look.

A note on timestamps

Kafka will add a publish time in the header of a message. However it can also be useful to include your own timestamps for some situations, such as when the data is gathered at a different time to when it is published, or when a retry implementation is needed. Also since using Apache Kafka allows additional consumers to reprocess records later, a timestamp can give a handy insight into progress through an existing data set.

If I could make rules, I'd make rules about timestamp formats! The only acceptable formats are:

Seconds since the epoch 1615910306
ISO 8601 format 2021-05-11T10:58:26Z including timezone information, I should not have to know where on the planet on which day of the year this payload was created.

Design with intention

With the size limitations on the payloads supported by Apache Kafka, it's important to only include fields that can justify their own inclusion. When the consumers of the data are known, it's easier to plan for their context and likely use cases. When they're not, that's a more difficult assignment but the tips shared here will hopefully set you on a road to success.

Manage Database Infrastructure with Aiven's API

Lorna Jane Mitchell — Tue, 30 Mar 2021 16:17:52 +0000

Perhaps you recognise Aiven as the multicloud platform for all your open source data needs, with the lovely web interface. And perhaps, if you didn't already, you recognise us that way now :) But Aiven is more than just a pretty web interface, we also have an API for all your integration/automation needs. In this post, we'll take a look at using the API and what you can do with it.

Meet the API

Aiven offers an HTTP API with token authentication and JSON-formatted data. A great place to start is the API reference documentation which gives you the details of all the endpoints. The API supports pretty much everything you can do with the web console ... because the web console uses the API too!

Get your auth token

To access the API, you'll need an access token. To obtain this, log into your Aiven account and go to your profile page; then under "Authentication Tokens" click "Generate Token". This prompts for a token description (for your own reference) and some expiry configuration. It's probably a good idea to set the token to expire after a while (for example, a week is 168 hours) but of course the choice is yours.

Copy the new token to somewhere safe, you won't be able to access it again.

If you lose your token, revoke it and generate a new one at any time. It's good practice to rotate tokens from time to time. Note to self: revoke the token used in these examples when this post is published!

First steps: using cURL

We'll be using the terminal for this section, so set the token you copied before as an environment variable:

export AIVEN_API_TOKEN=[paste]

Starting simple, try getting a list of projects using the API. Here's a cURL showing this in action.

curl -H "Authorization: aivenv1 $AIVEN_API_TOKEN" https://api.aiven.io/v1/project

I use this call quite often, because many endpoints take the project as a parameter. If reading raw JSON isn't your thing, then one option is to use a tool called jq to make things more readable. Pipe your curl output to it, like this:

curl -s -H "Authorization: aivenv1 $AIVEN_API_TOKEN" https://api.aiven.io/v1/project | jq ".project_membership"

This returns the fields we're most interested in: the project names and our role for each.

API calls with Postman

If you prefer a GUI application for trying out API calls, then that seems pretty reasonable to me! There are lots of options but for this example I'll be using my personal favourite, Postman. It's available as a cross-platform desktop app, or it can be used from the browser.

✨ Magic alert ✨ Since Aiven offers an OpenAPI description of the API, we can use this to get a ready-made set of collections to use in Postman!

Download the OpenAPI description file from the API documentation itself, using the "Download" button.

Import the OpenAPI file into Postman. This creates a new collection in the left hand bar called "Aiven".

On the left side of the window, right-click your new Aiven collection and select Edit. On the "Authorization" tab, on the Type drop-down, select Bearer Token. Copy your API token into the field on the right, or as shown in the screenshot, use Postman's variables feature to store this separately.

You're all set! Check things are working by looking in the "Project" folder in the collection and running the "List projects" request. Postman helpfully detects the JSON response and formats the output nicely for us.

Creating Aiven services from the API

We can do more than just fetch some data fields from the API; let's go ahead and create some services.

By default, Postman organises requests by URL segment, so we need to go digging at this point! Under "project" and then "{project}", it's the "Services" folder we want. And there: "Create a service" is the request to open.

On the "Params" tab, enter the project name that you will be using.

Check the Authorization tab has the type set to "Inherit auth from parent". This will pick up on the token or variable we configured on the collection earlier.

Creating services needs a specific JSON API structure to be sent to the API, but in the "Body" tab Postman already has the outline and we can add the values we want to use. This endpoint allows quite a lot of configuration but checking the API docs for the Create Services endpoint shows not all fields are required. In fact, this payload is enough to get a service going:

{
    "plan": "business-4",
    "service_name": "data-and-clouds",
    "service_type": "pg",
    "cloud": "google-europe-north1"
}

If all goes well, you will get a response with a 200 status, and some data about your new service! It takes a few minutes to be responsive but essentially that's all there is to it.

Wondering which other clouds you could choose? Try the list clouds endpoint and take your pick!

Whatever next?

We'd love to hear how you use our API in your workflow!

Depending what you're interested in, try some of these handy links next:

The Aiven API reference for more information on any of the endpoints not covered here
We also have a command line tool; an excellent addition to the developers' toolbox when working with Aiven
For infrastructure integration, try the Aiven terraform provider
Check out Postman, the HTTP client used in the examples in this post.

Go and PostgreSQL with pgx and squirrel libraries

Lorna Jane Mitchell — Fri, 26 Feb 2021 00:00:00 +0000

Applications and databases go together like milk and cookies; on the menu today is a PostgreSQL-flavored cookie with a splash of refreshing Go milk. I've picked two of my favorite Go libraries to show how to connect to and work with your Aiven PostgreSQL service. The libraries are pgx which is a nice PostgreSQL-specific alternative to database/sql and Squirrel because I love the name (it also has some quite cool features).

Start with a database

It would make sense to already have a PostgreSQL database handy, ideally with some data in it. If you don't already have an Aiven account, then sign up and start a PostgreSQL service. If you already have some data to use, great! I'm using some open data from the Kepler space mission, you can follow along with the recent blog post to set this up yourself.

In the Aiven Console, copy the connection string for Postgres - or if you are using a different database, copy the postgres://.... connection string.

Connecting to PostgreSQL from Go

Go has built-in database support in its database/sql library, but it's quite generic since it has to be able to cope with so many different database platforms. For applications that are specifically connecting to PostgreSQL, it make sense to use a specialist library.

For this example I chose jackc/pgx which is PostgreSQL-specific and has some nice features around understanding PostgreSQL data types in addition to improved performance. The overall pattern isn't radically different from other applications using database/sql, which makes it feel quite familiar.

Set the connection string you copied earlier as the DATABASE_URL environment variable. Then initialise your go application with go mod init pgfun; pgx uses go modules.

When you have everything set up, try the code example below to connect to a database and run one query (my database has the exoplanets data in it):


package main

import (
    "context"
    "fmt"
    "os"

    "github.com/jackc/pgx/v4/pgxpool"
)

func main() {
    dbpool, dberr := pgxpool.Connect(context.Background(), os.Getenv("DATABASE_URL"))
    if dberr != nil {
        panic("Unable to connect to database")
    }
    defer dbpool.Close()

    sql := "SELECT kepler_name, koi_score " +
        "FROM cumulative " +
        "WHERE kepler_name IS NOT NULL AND koi_pdisposition = 'CANDIDATE' " +
        "ORDER BY koi_score LIMIT 5"
    rows, sqlerr := dbpool.Query(context.Background(), sql)
    if sqlerr != nil {
        panic(fmt.Sprintf("QueryRow failed: %v", sqlerr))
    }

    for rows.Next() {
        var planet_name string
        var score float64
        rows.Scan(&planet_name, &score)
        fmt.Printf("%s\t%.2f\n", planet_name, score)
    }
}

In the main() function, first the code connects to the database using the connection pool features of pgx. As a general rule I consider that pooling connections for PostgreSQL is a wise move which is why it's used here.

Then a simple SQL statement that shows the exoplanets that the Kepler mission assigned a "CANDIDATE" status, and how confident they were that it was a real planet. The statement has a row limit (the dataset has ~2k rows without the limit) so you only see the five lowest-confidence-scoring planets in the final section that iterates over the rows and reads the data in as variables.

I love that the names are here - if you're interested you can even look up the planets in the Exoplanet Catalogue. I spent way too much time browsing that, science is ace!

So to recap, we have one PostgreSQL connection string, one Go database library and a hardcoded SQL query. What's next?

Fluid Interfaces with Squirrel

While the pgx library is a PostgreSQL-specific alternative to database/sql, it also has a compatible interface. This is ideal if you want to switch an existing application over, but it also means that other tools designed to play nicely with database/sql can work with pgx too. That's good news for me because I want to find something more elegant than my hardcoded SQL string.

Squirrel!

No, I didn't get distracted, it's an SQL library. Although, it is a bit of a shiny toy. It's a fluid interface for building SQL queries, and SQL lends itself well to being thought about in this way.

Rebuilding our existing SQL query in this interface produces something like this:

    planets := psql.Select("kepler_name", "koi_score").
        From("cumulative").
        Where(sq.NotEq{"kepler_name": nil}).
        Where(sq.Eq{"koi_pdisposition": "CANDIDATE"}).
        OrderBy("koi_score").
        Limit(5)

It's a bit more manageable and I can imagine building this in a real application much more easily than concatenating bits of SQL string together. It's still possible to inspect the SQL that it built as a string by calling planets.ToSql(), which is a nice touch.

Switching pgx over to the "pretend to be database/sql" mode needed a little refactoring. I also need a spoonful of secret sauce to make Squirrel play nicely with PostgreSQL, so here's the whole runnable example at once. It expects the database connection string to be in DATABASE_URL as for the previous example:

package main

import (
    "database/sql"
    "fmt"
    "os"

    sq "github.com/Masterminds/squirrel"
    _ "github.com/jackc/pgx/v4/stdlib"
)

func main() {
    db, err := sql.Open("pgx", os.Getenv("DATABASE_URL"))
    if err != nil {
        panic("Unable to connect to database")
    }
    defer db.Close()

    // a little magic to tell squirrel it's postgres
    psql := sq.StatementBuilder.PlaceholderFormat(sq.Dollar)

    planets := psql.Select("kepler_name", "koi_score").
        From("cumulative").
        Where(sq.NotEq{"kepler_name": nil}).
        Where(sq.Eq{"koi_pdisposition": "CANDIDATE"}).
        OrderBy("koi_score").
        Limit(5)

    rows, sqlerr := planets.RunWith(db).Query()
    if sqlerr != nil {
        panic(fmt.Sprintf("QueryRow failed: %v", sqlerr))
    }

    for rows.Next() {
        var planet_name string
        var score float64
        rows.Scan(&planet_name, &score)
        fmt.Printf("%s\t%.2f\n", planet_name, score)
    }
}

Note that the pgx import is different this time to get the database/sql compatible library that Squirrel expects in its RunWith() method. The connection step changes a little as well so don't try to amend the previous example; this one is different.

The psql variable holds a reconfigured squirrel which is needed because PostgreSQL handles placeholders slightly differently. Skipping this causes the code to tell you there is a syntax error near the LIMIT clause. Hopefully now I've written this down my valued readers can avoid this problem, and I may even remember this next time too!

Fun with Go and PostgreSQL

This was a lightweight introduction to show you a couple of my favourite libraries for Go and PostgreSQL applications - and of course with an open data set to play with, the fun is multiplied :)

Here are some related links and further reading, reach out to us on Twitter if you have questions. We are always pleased to chat.

Getting Started with Aiven PostgreSQL
Importing Exoplanets into your PostgreSQL
Code examples for Aiven connections
Postgres13 is Available

Discover exoplanets with PostgreSQL sample data

Lorna Jane Mitchell — Wed, 17 Feb 2021 00:00:00 +0000

PostgreSQL is and remains one of our most popular and strongly growing storage platforms. Other storage technologies come and go but modern Postgres is a solid choice for so many applications. In this article we'll take a look at how to get started with Aiven for PostgreSQL, populate it with data and start playing.

When you spin up your first Aiven for PostgreSQL, you'll want to take some time to play with the features ... but there's a problem. Your new shiny database is empty.

Finding and using some open datasets is a great way to fill this gap. One option is go try the Kaggle platform. It's a place to find open data, advice about data science, and some competitions you can participate in to hone your skills. There's quite a selection of datasets to choose from, but today I'll be using the exoplanets data from the Kepler mission. You'll need a (free) account to log in and download the data. Go ahead and extract the zip file, I'm using cumulative.csv for the example in this post.

Get Started with Aiven

If you are not already an Aiven user, you can sign up for an Aiven account to follow the steps in this post - we'll wait right here!

We will also be using the Aiven CLI. This tool requires Python 3.6 or later, and can be installed from PyPI:

pip install aiven-client

You also need to authenticate your Aiven account against the CLI tool. Run the following command, substituting your own details:

avn user login <email@example.com>

You now have everything you need to create an Aiven database in the cloud.

Create PostgreSQL Service

A good first step is to create a project to keep the services in. All it needs is a name:

avn project create exoplanets

Aiven offers many options when creating services but to get us going quickly, I'll use the newest postgres available and the smallest package, called "hobbyist". One of the most fun things though is being able to choose any cloud platform you like! Take a moment to check the list and copy the CLOUD_NAME field of your favorite:

avn cloud list

I chose google-europe-west1 for my example. Here is the command to run to create the Postgres database (remember to swap in the cloud of your choice):

avn service create -t pg -p hobbyist --cloud google-europe-west1 pg-exoplanets

The node takes a few minutes to be ready, but the Aiven CLI has a handy "wait" command that doesn't return until the service is ready to talk to us. This is less critical for running the commands by hand as I have here, but it's super useful when your CI system is spinning up the data platforms by itself!

avn service wait pg-exoplanets

When the command returns, my PostgreSQL cluster is ready to use. Let's create a database to hold the sample data; the command below creates one named "exoplanets":

avn service database-create --dbname exoplanets pg-exoplanets

Now I have a shiny new database... but it's all sad and empty. Let's look at the sample data and get it imported.

Adding CSV Data to PostgreSQL

PostgreSQL has built-in support for importing CSV data into an existing table, but I don't have the table structure, just a CSV. Luckily there's a tool for that - ddlgenerator is another Python commandline tool.

Here's how to install the ddlgenerator tool and then generate the CREATE TABLE statement from cumulative.csv that I downloaded earlier:

pip install ddlgenerator
ddlgenerator postgres cumulative.csv > create.sql

Have a look inside the file and you will see that it has the structure I need to explain to PostgreSQL how to hold the data. The avn service cli command will give us a psql prompt on the new database:

avn service cli pg-exoplanets

From within psql I can connect to the "exoplanets" database, and then run the SQL file to create the table structure:

\c exoplanets
\i create.sql

Adding the final piece to the puzzle, and still from the psql prompt, the next command brings in the CSV data:

\copy cumulative from data/cumulative.csv csv header

Nice work! The cumulative table should now have some data for you to play with!

Dreaming of Exoplanets

Now you have a database full of measurements of exoplanets taken by the Kepler Space Telescope. If you're not already familiar with the project, the NASA mission page is worth a read. The mission went into a second phase when one of the controls failed, which serves to remind us that engineering systems we can see and touch, or at least ssh into, is much easier gig than operating in space!

You can explore the dataset, which describes observations and compares the Kepler assessment of each exoplanet with its official status in the pre-existing literature. For example, try this to see the false-positives identified by Kepler:

select kepler_name, koi_pdisposition from cumulative where koi_disposition = 'CONFIRMED' and koi_pdisposition = 'FALSE POSITIVE';

You can also connect this data to other tools to use the dataset further. Either grab the connection details from the web console, or use jq with avn for a one-liner:

avn service get pg-exoplanets --json | jq ".service_uri"

What's Next?

Good cloud experimentation practice suggests that if you've finished with your exoplanets database, you can delete it:

avn service terminate pg-exoplanets

For even more fun and learning, how about one of these resources:

Kaggle Open Datasets in case you don't fancy exoplanets, there are some excellent alternatives here
In our documentation you can find instructions for migrating your existing PostgreSQL to Aiven
More about the Aiven CLI, avn
Need more PostgreSQL? Check out our introduction to PostgreSQL post

Kafka v. RabbitMQ - a comparison

Lorna Jane Mitchell — Mon, 01 Feb 2021 00:00:00 +0000

Kafka v. RabbitMQ - a comparison

Today's post is all about queues and how to choose a solution that fits your application's requirements. We'll go over the key design features of RabbitMQ and Kafka and outline how they process queues differently. Read on, and we'll help you decide which is a better match for you!

There are many roads that can lead to the moment you decide you need a queue. Queues are an excellent way to loosely couple many different components and allow them to exchange data without detailed knowledge about one another. Using a queue is also an excellent way to distribute work between multiple nodes to perform asynchronous tasks.

Queues come in different flavours and success is morely likely when you can use the queue that best fits the shape of your use case. There's some overlap between the use cases but in general it can be summarised as choosing between a job queue and a message queue.

Processed and Forgotten: RabbitMQ

A job queue such as RabbitMQ is a good choice when work is being delegated to an asynchronous endpoint, such as a serverless function. The classic example is resizing an image. When a user uploads a new image, the application needs to produce a thumbnail or some custom sizes for that image, but the user shouldn't have to wait for that work to be completed before getting on with what they were doing. So we can put the request onto a queue and carry on with generic placeholder images, until the resizing is complete.

RabbitMQ is a popular message broker and is a good fit for those job-shaped application requirements. It's an open source tool and here at Aiven we're big fans of all the open source tools. RabbitMQ supports multiple protocols, has predefined exchange types and has configurable flexible routing. When you work with a job queue, the message broker transports the messages to the place where they are processed. The job gets processed once (technically "at least once"), and then it is completed and is removed.

Event-Driven Application: Apache Kafka

In contrast with the RabbitMQ model, message queues can also be more of data bus in architecture terms, a conduit for communicating the events throughout the application. A message (called a "record" in our favourite message queue tool, Kafka is put onto the bus and then any interested consumers, now or in the future, can access and consume the message. The message persists so that other consumers can also access the data, either at the time that the data is added ("produced" in Kafka terminology) to the message bus, or later if we decide we want to revisit the data for additional analysis.

We commonly see Apache Kafka used in event-driven applications where data must flow between multiple components in the application. Using this distributed message bus model gives a great deal of scalability and it's not a coincidence that the roots of the open source Apache Kafka tool are in the software stack of LinkedIn, a company with a lot of data and many components consuming it. Kafka is a distributed log of past events, which gives the advantage that every past change is also always still available, so you can build features based on the events or simply have the peace of mind that the data will always be availabe for inspection or audit if needed.

Kafka is quite approachable as a technology, you can either install it yourself or take up the free trial available on the Aiven platform to get started. It's ideal for getting to know the technology, with a friendly web interface to get you on the right track and a selection of connectors that can be added easily. It can be scaled up to handle colossal workloads and we see some very large clients with some great performance on our platform.

More Resources

Thinking about the shape of the data requirements that you have will ensure you pick a queue that works for you. If it's a task on a task list, then try RabbitMQ. But for data that needs to flow around your application and drive multiple integrations, Kakfa is probably your best bet. If you'd like to know more, then some of these links may be useful:

Of course, we'd love you to try Kafka on the Aiven platform if you read this far and think you have Kafka-shaped requirements! Sign up and let us know what you build.

How to Send WhatsApp Messages With Laravel

Lorna Jane Mitchell — Mon, 26 Oct 2020 14:31:25 +0000

Take two things that we love: WhatsApp messages and Laravel framework. Mix them together. What do you get? Fun with phones!

This tutorial shows you how to create a Laravel application that sends and responds to WhatsApp messages.

You will need:

A PHP development platform (Laravel 8 requires PHP 7.3 or later)
WhatsApp on your phone

Vonage API Account

To complete this tutorial, you will need a Vonage API account. If you don’t have one already, you can sign up today and start building with free credit.

Once you have an account, you can find your API Key and API Secret at the top of the Vonage API Dashboard.

Get the Code Running

The project is on GitHub at nexmo-community/laravel-messages, so go ahead and clone that repository to your computer.

Run the command composer install to get the dependencies needed for this project.

This application uses the phpdotenv library to manage its configuration on a dev platform. Copy the file .env.example to .env and edit the file as needed. In particular, you should update the NEXMO_API_KEY and NEXMO_API_SECRET lines at the end of the file to connect your Vonage account (we used to be called Nexmo, and old habits die hard!)

The application is ready to go! Start it with:

php artisan serve

By default, this will run your application on port 8000. Check that you have a Laravel homepage on http://localhost:8000 before moving on.

Set Up Ngrok

Since the application needs to be able to receive incoming webhooks for two-way messaging communication, we need a way to allow public URLs to access the dev platform. I usually use Ngrok for this; it’s an excellent tool.

Start an Ngrok tunnel to port 8000 (or whatever port your application is running on):

ngrok http 8000

This starts an in-terminal console, so it looks something like this:

Copy the “Forwarding” https URL. We will need this shortly to configure the Vonage Messages API sandbox. You can also check everything is wired up by requesting this URL in your browser and seeing the same Laravel landing page as before.

Configure the Messages Sandbox

To get incoming WhatsApp messages directed to your application, we need to do a little bit of configuration in the dashboard. Under “Messages and Dispatch,” click on “Sandbox” we will use the Messages API Sandbox for the demo today, but if you have a WhatsApp Business account, you could use the same approach to message any user without the Sandbox or whitelisting process.

Add your phone number to the Sandbox by scanning the QR code or messaging the magic words to the number shown. I am not sure why I enjoy the magic words “auth method” so much, but it really seems like magic!

Time to configure the webhooks, and you will need the URL copied from the ngrok console earlier.

Inbound should be [url you copied earlier]/webhooks/inbound
Status should be [url you copied earlier]/webhooks/status

Don’t forget to press “Save” here! That seems to trip me up more often than it ought to.

Inside the Code

Let’s look at the various routes set up in this application and how they interact with the Messages API.

Sending From Laravel

The best place to start with this application is at http://localhost:8000/messages where you can add your phone number and send yourself a message.

Note that the number needs to be in the international (E.164) format without a leading +. So for US numbers, start with 1 and then add the full number with area code. For the UK, start with 44 and then add the whole number without the leading 0.

Here’s what happens when that form gets submitted:

// in routes/web.php

Route::post('/message', function(Request $request) {
    // TODO: validate incoming params first!

    $url = "https://messages-sandbox.nexmo.com/v0.1/messages";
    $params = ["to" => ["type" => "whatsapp", "number" => $request->input('number')],
        "from" => ["type" => "whatsapp", "number" => "14157386170"],
        "message" => [
            "content" => [
                "type" => "text",
                "text" => "Hello from Vonage and Laravel :) Please reply to this message with a number between 1 and 100"
            ]
        ]
    ];
    $headers = ["Authorization" => "Basic " . base64_encode(env('NEXMO_API_KEY') . ":" . env('NEXMO_API_SECRET'))];

    $client = new \GuzzleHttp\Client();
    $response = $client->request('POST', $url, ["headers" => $headers, "json" => $params]);
    $data = $response->getBody();
    Log::Info($data);

    return view('thanks');
});

This route uses Guzzle to send a POST request to the Messages Sandbox, and if the credentials are correct and the supplied phone number is whitelisted to the application, it will send the message you can see defined here. The message prompts the user to reply, so let’s see that code next.

Receiving and Responding to WhatsApp Messages

With the webhooks configured in the dashboard and the Ngrok tunnel running, the local development application can receive incoming WhatsApp messages. If you already replied to the challenge to supply a number, then you know what happens next

Here’s the code:

// in routes/web.php

Route::post('/webhooks/inbound', function(Request $request) {
    $data = $request->all();

    $text = $data['message']['content']['text'];
    $number = intval($text);
    Log::Info($number);
    if($number > 0) {
        $random = rand(1, 8);
        Log::Info($random);
        $respond_number = $number * $random;
        Log::Info($respond_number);
        $url = "https://messages-sandbox.nexmo.com/v0.1/messages";
        $params = ["to" => ["type" => "whatsapp", "number" => $data['from']['number']],
            "from" => ["type" => "whatsapp", "number" => "14157386170"],
            "message" => [
                "content" => [
                    "type" => "text",
                    "text" => "The answer is " . $respond_number . ", we multiplied by " . $random . "."
                ]
            ]
        ];
        $headers = ["Authorization" => "Basic " . base64_encode(env('NEXMO_API_KEY') . ":" . env('NEXMO_API_SECRET'))];

        $client = new \GuzzleHttp\Client();
        $response = $client->request('POST', $url, ["headers" => $headers, "json" => $params]);
        $data = $response->getBody();
    }
    Log::Info($data);
});

This example probably isn’t exactly what you’d want your application to do, but it includes the moving parts you might need! The incoming webhook arrives, and we grab the data and try to read the message content as an integer. We do a little fun maths operation with a randomly generated number and send a reply to the user exactly as we did in the first code example.

You could also use the Laravel HTTP Client in place of Guzzle if you’re more familiar with that. The Laravel HTTP Client is a wrapper for Guzzle.

Status Updates

Remember the status webhook we configured earlier? Events about the messages such as when they are submitted (sent from Vonage to WhatsApp), delivered (arrived on the user’s device), and read (the user opened the message) are delivered to this endpoint. This application doesn’t do a lot with them, but it is great to have access and be able to respond to them.

The status endpoints are also pretty handy for debugging. The route in the example application looks like this:

// in routes/web.php

Route::post('/webhooks/status', function(Request $request) {
    $data = $request->all();
    Log::Info($data);
});

So it just logs each event as it happens. Logging is incredibly valuable when debugging issues! By default, you can find these logs in storage/logs/laravel.log and it is well worth keeping an eye on what is happening in that file as you develop an application like this one!

Fun With Phones

If you didn’t try it already, then go ahead and enjoy a WhatsApp chat with your application.

Today’s example is simple but hopefully serves to get you started with WhatsApp and Laravel. We would love to know what you build, so let us know, and of course, always reach out to us if you have questions!

More Resources

GitHub repo: https://github.com/nexmo-community/laravel-messages
The day we built this on our Twitch Stream: https://youtu.be/aV4IW3v-CTw
Documentation for Messages Sandbox: https://developer.nexmo.com/messages/concepts/messages-api-sandbox
The nexmo-laravel library for integrating your Laravel application with other Vonage APIs https://github.com/Nexmo/nexmo-laravel

The post How to Send WhatsApp Messages With Laravel appeared first on Vonage Developer Blog.

Surviving Hacktoberfest: A Guide for Maintainers

Lorna Jane Mitchell — Tue, 13 Oct 2020 13:28:53 +0000

Vonage is thrilled to be a Hacktoberfest 2020 partner. We’re no strangers to open source, with our libraries, code snippets, and demos all on GitHub. To fully immerse yourself in the festivities, be sure to check out our Hacktoberfest page for details on all that we have planned!

Happy Hacktoberfest to one and all! Contributors, I hope you are having a wonderful time learning new skills and discovering projects where you can make a difference. Maintainers, today’s post is just for you. Hopefully, the rules changes mean a better quality of pull requests for your projects, but it can still be a lot to handle. I’m a long-time maintainer, and today I’d like to share some tips that I hope will help you through.

Let’s Talk Priorities

Open source project maintainers are mostly doing this work in their “spare” time, and it’s a lot. It’s not just for Hacktober, and a lot of the work can be rather unseen. This Hacktoberfest, especially with global events around us, it’s important to consider your priorities and to keep sight of them!

I’d suggest that you, your project, and then its contributors, in that order, is a good order of priorities. A project is nothing without maintainers, and many are teams of one. The aims and goal of the project is an important priority; there’s no pressure to expand the scope or pivot the project because a pull request arrived to do that. The joy of open source is that people can use their own forks as the basis of a new project if they don’t like the way you run things! And finally the contributors; Hacktoberfest has a lot of new contributors, but we want to raise them to be contributors, not spoilt children. So if they need to read the project guidelines before contributing, then say so rather than doing a lot of re-work yourself.

Handling Notification Fatigue

Hacktoberfest is now opt-in, but if you are “in”, then it’s easy to feel overwhelmed, especially on a high profile or already-busy project. Key to coping is to manage your notifications. And no, an email rule to just file or delete everything with your project name in it is not the answer!

Take some time with your GitHub notifications setup to make sure you are being notified when you want to be, and not being notified with too much that isn’t relevant. You can also route different notifications for different orgs to different email addresses, which can be very useful.

Configure and Route Emails

GitHub has excellent help documentation, so I won’t repeat their content here, but I’ll direct you to the places I find the most useful!

First, you can link multiple email addresses to one GitHub account, which is useful if you do some work projects with your GitHub account, or use a different email address for a particular open source project. Take a look at the documentation for verifying additional email addresses on GitHub.

Next, get the right notifications going to the right email address. It’s under “custom routing” in the notifications configuration, and of course, there is excellent documentation on routing emails on GitHub.

Watch and Unwatch

The ability to “Watch” a repo is very valuable. If there’s a project you want to get all the notifications for, click the “Watch” button at the top and choose “Watching”. This is useful if you need to keep track of activity in a particular repo.

Perhaps more valuable is the ability to “unwatch” a project! I find that because I do some of the GitHub maintenance at work, I have access to many repositories, and by default, if you have access, you are subscribed to the notifications! This can be pretty noisy as you can imagine, so the same “Watch” button gives us some other options – the default is “Not Watching”, so you’ll get notifications on your own issues/PRs or if you’re mentioned. You can also set it to “Ignoring” if you’re getting involved when you don’t want to be.

Subscribe and Unsubscribe

On a per-repo level, you can also get notifications without having to comment on the discussion to make yourself “participating”. Look for the button on the right-hand side labelled “Subscribe” under “Notifications”. Again, there’s an opposite option too! Suppose you’ve chimed in on something that you’re no longer interested in getting notifications for. In that case, you can “Unsubscribe” from just one issue or pull request without having to unsubscribe from a whole repository.

Move Quickly

If a pull request isn’t useful or doesn’t meet the project goals, don’t be afraid to reject it. The Hacktoberfest FAQ is your friend here. Always be friendly – but quick responses are valuable if you have the availability to keep up with things every few days. If a pull request could be made acceptable, for example, because it makes the build fail but can be corrected, offer some feedback to your new contributor explaining what would make the pull request ready to merge. If it’s a change you don’t want (emoji to decorate your README seems a popular contribution), then say so and close it.

Open source isn’t always a welcoming place, and we operate in public, so bystanders get a good impression of our projects by the way we interact with people. Take the time to thank people for their input! Even if the pull request isn’t worth the time it took you to read it, a simple “This doesn’t seem useful to the project, why not check the issue list for ideas?” is much more welcoming than closing with no other communication or explanation.

Thankyou

On that note of thanking contributors, I’d like to close by thanking you, the maintainer. It’s a common misconception that open source projects are maintained by some amazing, distant, heroic figure. In fact, those of us who give our time and energy in this way are real people with real lives.

Thank you for all that you do, open source changes the world, and in your own way, you’re making that happen.

The post Surviving Hacktoberfest: A Guide for Maintainers appeared first on Vonage Developer Blog.

DEV Community: Lorna Jane Mitchell

Get to know the Aiven API with Postman

Before you start

Get your head in the clouds

Send credentials with your API request

Create a cloud database

Power off the services when you don't need them

Postman, Aiven and APIs

Add Aiven database magic to your Laravel project

Set up the Aiven-Laravel package

Configure Laravel to use an Aiven service

Avoid cloud bill surprises

Aiven-Laravel and you

M3 for Metrics

Start with something to monitor

Collect metrics with Aiven for M3

Visualize the data with Grafana

Integrations in action

Further Reading

A Developer's First Impression of M3DB

M3 speaks Prometheus

M3 speaks InfluxDB

Grafanical ease of integration

Identifying Time Series Data

Start with something to monitor

Collect metrics with Aiven for M3

Visualize the data with Grafana

Integrations in action

Further Reading

Tips for Designing Apache Kafka Message Payloads

Use all the features of Apache Kafka records

Data structures: nested data or simple layout?

Data Formats: JSON, Avro ... these are not real words

A note on timestamps

Design with intention

Further reading

Manage Database Infrastructure with Aiven's API

Meet the API

Get your auth token

First steps: using cURL

API calls with Postman

Creating Aiven services from the API

Whatever next?

Go and PostgreSQL with pgx and squirrel libraries

Start with a database

Connecting to PostgreSQL from Go

Fluid Interfaces with Squirrel

Fun with Go and PostgreSQL

Discover exoplanets with PostgreSQL sample data

Get Started with Aiven

Create PostgreSQL Service

Adding CSV Data to PostgreSQL

Dreaming of Exoplanets

What's Next?

Kafka v. RabbitMQ - a comparison

Kafka v. RabbitMQ - a comparison

Processed and Forgotten: RabbitMQ

Event-Driven Application: Apache Kafka

More Resources

How to Send WhatsApp Messages With Laravel

Vonage API Account

Get the Code Running

Set Up Ngrok

Configure the Messages Sandbox

Inside the Code

Sending From Laravel

Receiving and Responding to WhatsApp Messages

Status Updates

Fun With Phones

More Resources

Surviving Hacktoberfest: A Guide for Maintainers

Let’s Talk Priorities

Handling Notification Fatigue

Configure and Route Emails

Watch and Unwatch

Subscribe and Unsubscribe

Move Quickly

Thankyou