Motivation

Finding the desired link again can be sometimes a tedious job. It can even become frustrating when you don’t find it in a reasonable amount of time, because you know it’s there somewhere, you visited it before… After a struggle of about two or more minutes you finally find it.

This time you bookmark it and then you say to yourself - “from now on I will be more disciplined and consciously use bookmarks”.

bookmark (verb) - record the address of (a website, file, etc.) to enable quick access in future.

So far, so good. The problem is your bookmarks can turn into a monster themselves and you can later lose then more time browsing through them to find the right one, because you know now you bookmarked it…

So you are developing a core platform for your enterprise. Your platform becomes successful, you have more clients consuming your services. Some (most) will need some core data synchronized in their systems. You might start experiencing the following pains

Pains

1. You might use a push mechanism to notify clients about an core element update (e.g. user or organisation data update). But what happens when a new client ist added? Well your core platform needs to be aware of it. This might imply code or configuration changes, new deployments etc. - ** it does not scale **
2. If a client of the platform is not online the time the update notification is pushed, it will miss the update, which might lead to data inconsistency.

Pub/Subscribe to the rescue

Both issues are elegantly solved if you use a publish/subscribe mechanism. Your core platform, the publisher, will publish the update event to a message broker, that will be consumed by one or several clients, subscribers. See the diagram below for the 1000 words, worth of explanation:

Last week I showed you how to increase the performance of multiple java calls by making them asynchronous and parallel. This week we take a look at another potential performance booster, you should always keep in mind - caching.

Let’s imagine a scenario where you call a REST service and you know the returned values don’t change very often. In this case you really need to consider caching the response. We will use Guava’s provided caching capabilities to implement such a cache for this example.

Some time ago I wrote how elegant and rapid is to make parallel calls in NodeJS with async-await and Promise.all capabilities. Well, it turns out in Java is just as elegant and succinct with the help of CompletableFuture which was introduced in Java 8. To demonstrate that let’s imagine that you need to retrieve a list of ToDos from a REST service, given their Ids. Of course you could iterate through the list of Ids and sequentially call the web service, but it’s much more performant to do it in parallel with asynchronous calls.

I have a use case where I need to retrieve the latest public bookmarks public added on www.codever.dev. They are store in a mongo database, and I use Mongoose as ORM.

I want to have two possibilites to achieve this:

1. specify the number of days to look back
2. specify the timestamp since when to look forward

I think the code is self explanatory

/**
 * Returns the bookmarks added recently.
 *
 * The since query parameter is a timestamp which specifies the date since we want to look forward to present time.
 * If this parameter is present it has priority. If it is not present, we might specify the number of days to look back via
 * the query parameter numberOfDays. If not present it defaults to 7 days, last week.
 *
 */
router.get('/latest-entries', async (req, res) => {
  try
  {

    if(req.query.since) {
      const bookmarks = await Bookmark.find(
        {
          createdAt: { $gte: new Date(parseFloat(req.query.since,0)) }
        }).sort({createdAt: 'desc'}).lean().exec();

      res.send(bookmarks);
    } else {
      const numberOfDaysToLookBack = req.query.days ? req.query.days : 7;

      const bookmarks = await Bookmark.find(
        {
          createdAt: { $gte: new Date((new Date().getTime() - (numberOfDaysToLookBack * 24 * 60 * 60 * 1000))) }
        }).sort({createdAt: 'desc'}).lean().exec();

      res.send(bookmarks);
    }

  }
  catch (err)
  {
    return res.status(500).send(err);
  }
});