-2

We're building a PDF service for internal use, to permit common operations like HTML to PDF, merging PDFs, extracting pages, convert to/from other formats, etc. We intend to use a queueing mechanism so everything would be async. The only thing we're trying to decide is whether or not we should front the queue with a REST API (so you'd post to a REST API and that would just write to a queue and return a response). If this was a public facing thing that we're providing for clients it would be a no-brainer, but given it's internal only, I'm trying to think of pros/cons.

When it comes to pros, I think people are used to reason around REST APIs, you can automatically publish documentation with something like Swagger, and you could also call it from a JS front-end directly (authenticating with oAuth/OIDC) if the need arose. You can also wrap more functionality into it. For example, for a conversion operation, you can upload the file through REST and the service takes care of saving in S3, then post message with the link in it.

Cons for REST, you're introducing another layer that may not be required. You now have HTTP in the middle and have to deal with that, including the network overhead that can go with that. If you have a ton of messages you want to get through, you may need to consider a bulk API call instead of making a gazillion REST calls.

Pros for direct to queue, you can just setup permissions for the queue and drop messages directly to it. HTTP is no longer really part of the equation, just know the message format and drop a message on a queue. Simplicity, to a certain degree (but maybe not, as shown by cons), less overhead.

Cons, you can't have anything external easily access this or a JS front-end (as far as I know). Also, you may need to manage multiple operations separately before you can post to queue. While you can send files through SQS, you may have limitations in size there that are best avoided. So you'd need to post files to S3 separately, then write to the queue, losing some of the simplicity you supposedly had from using a queue directly.

I'm leaning towards REST API. Any additional considerations anybody could point out?

Improve this question

1 Answer 1

Reset to default
2

If you haven't identified an actual need for REST or any other middle layer then why build it?
If it turns out you do need one then add it on. Chances are if you build it now you won't have thought of everything anyway, so wait for requirements and design to those.
There's little to nothing wrong with having a direct queue internally provided you configure it all nicely and avoid hard-coding it everywhere.

Side note: I don't think this is specific to PDF or even REST + Queue. You might want to alter the title to something like "should I build additional entry points/layers in front of my internal services/queues before I know I need them?"

Improve this answer
1
  • I kept the PDF service reference because there was content specific to that, namely potentially needing to upload PDFs separately if using queue vs uploading them through a REST service and as such wrapping everything into that operation. I guess that could fall into a requirement, and as you say if it is then maybe that means I need to go the REST route. I'm just trying to make sure I'm not overlooking something. If you haven't thought of it, you can't factor it in a decision. I do appreciate the answer.
    – Rocket04
    Jun 9 at 12:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.