Resolver v3.0 imminent - and data-entry is as backwards compatible as possible

[nicklansley]

Hello!

UPDATE: We're just running through a final slew of tests for GS1 Resolver Community Edition v3.0 and we intend, barring any sudden test horrors, to publish it in beta form on 9 May 2024.

The reason for publishing in 'beta' is simply that not all the new documentation will be ready, and there may be some anomalies to tune out and bugs to fix. However, several members of Resolver CE's developer community wanted to assess the architecture and work out what impact it would have when integrating it.

We'll move soon enough to release candidate when we think everything is OK, and some final community testing (including ourselves) will tune out and tune up the service ready for it to be declare production ready.

The good news is that pert of the testing is to make sure that the data entry API is as backwards-compatible as possible in terms of document uploads. This means that you will be able to upload documents in the v2.x format as well as the new and much simpler v3.0 format for the purpose of continuity.

Just a heads-up that the new Docker-based architecture for v3.0 will consist of four (no longer six) containers:

1. MongoDB database service
2. Data Entry service
3. Resolving (web) service
4. Proxy server that routes traffic to API or web - useful 'out of the box'.

Two containers are dropped:

• No relational database so the v1.x/v2.x SQL Server is dropped
• No separate GS1 Digital Toolkit service - that work will be integrated into data entry and web services

There are no more 'accounts' - originally resolver v1/v2 of needed to be self-standing with independent logins. No more! There is an authentication key that can be set as a secret and provided by the calling client when acting on the Resolver CE data entry API. Alternatively, you can easily replace our simple 'Bearer' authentication with your own authentication mechanism. You would likely run the data entry service on your internal network and accessed by your existing applications, with only the Resolving web server facing the internet - although they are both accessible via the provided proxy server 'out of the box'.

Indeed, part of the innovative design is to make it possible to run Resolver CE v3.0 with just two containers:

1. Data Entry service running on your internal network
2. Resolving (web) service on the internet surface at id.<yourdomainname.com>

We can certainly foresee both these containers running as Azure Container Functions or similar inexpensive services on other cloud platforms.

MongoDB?
You could use a Mongo-cloud based solution such as MongoDB Atlas or Cosmos DB with Mongo APi connector. You then supply the connection string as an environment variable to data entry and web containers.

Proxy server?
This container is just there to route incoming requests to data-entry and resolving (web) containers via a single endpoint through Docker or Kubernetes. Most of you have your own "front-door" routing services to your network applications, so you would just use that with appropriate rules.

OK then, an exciting week ahead for all of us! I'll keep you up to date here so please watch the discussion thread and take part as needed.

Cheers
Nick

[nicklansley]

UPDATE: We're pushing S1 Resolver Community Edition v3.0 in beta form to this project during the course of Thursday 9 May 2024.