Skip to content
This repository has been archived by the owner on Jun 29, 2020. It is now read-only.

Server(s) and API Endpoints

Jump to bottom
Stephanie Kwak edited this page Sep 29, 2016 · 27 revisions

Front-End Server

The front-end server is hosted via PHP Web Hosting. On the server is PHP 5.3.6 and Ruby 1.8.5.

  • Total amount of RAM: 16.042gb
  • Used: 15.849gb
  • Free: 192mb
  • Cached: 10.302gb

List of other features.

How to Get In

You can ssh into the server by running ssh pcahweb@trivium.phpwebhosting.com and entering the password pcah1608.

Superglue API

(Possibly separate from the front-end server)

Implementation options that were mulled over and considered:

  1. PHP Togetherness Use the existing server that is hosting the front-end (in Kirby 2) and use PHP to build out the API.
    • Pros: Same language used across the stack.
    • Cons: Lack of familiarity with PHP among the developers. Could run into server limitations.
  2. A Separated Ruby Spin up a new server and write out the API in (a more current version of) Ruby.
    • Pros: Dev familiarity with Ruby.
    • Cons: Adds a layer of complexity. Since we will be dealing with possibly large amounts of data being passed around, we will have to think about latency, etc.
  3. PHP + Ruby Mashup Run a Ruby app on the existing server with a cgi-bin script...
    • Pros: Could then use Ruby on the existing server.
    • Cons: Could be very slow.
  4. The Serverless Frontier Invoke an AWS Lambda function that processes the PDFS with AWS Gateway or through an app running the AWS SDK
    • Pros: Don't have manage a server that processes the PDFs. Have a few language options (Node, Python, Java).
    • Cons: Would have have to transfer PDFs and get a response back, which could be potentially slow. More moving parts and AWS and Lambda are notorious for changing things up. Possibly poor error handling.

Frameworks, Libraries, et cetera

The PHP Way (using the existing server)

PHP Options For Combining PDFs

  • libmergepdf
  • FPDI (There are other options but kept it to the more recently-maintained and used packages)

The Ruby Way

Ruby Options For Combining PDFs

  • CombinePDF (There are other options but kept it to the more recently-maintained and used packages)

Node, Python Options For Combining PDFs (for use with AWS Lambda)

Other Combining-PDF-Examples

Possible Endpoints

Some of the endpoints thought over in relation to the implementations:

  1. POST request to /api/pdf?id=id1,id2,id3&title=Superglued%20PDF (Superglue would exist on the front-end server)

    A simpler, though possibly more coupled approach, could be to stitch together PDFs that are known to the server in some way (like through IDs).

    The user could send a POST request to the API (/api/pdf?id=id1,id2,id3&title=Superglued%20PDF).

    • In this case, the files are stored physically on the disk and have an associated ID, which allows the server to know which files to combine. The combined PDF would be sent (named with the requested title) as a response back to the client.
    • Pros: Simpler. Because the files are physically on the disk, this would make the act of combining and sending much faster.
    • Cons: API not as reusable.

  2. POST request to /api/pdf?data=base64forever&title=Superglued%20PDF (Superglue would exist on a separate server)

A more complicated approach could be to aggregate the PDFs together (as a zip file sent as a base64 string, for instance) and send them via a POST request to the API. In this case, there may be additional things to consider and factor in, such as request limits and speed of receiving and sending PDFs using this approach.

  1. POST request to /api/pdf?urls=path/to/pdf1.pdf,path/to/pdf2.pdf (Superglue would exist on the front-end server)

A third approach would use paths as identifiers. The API would have to know what the web root is to read the files relative to it's own position, and would require both apps to be hosted on the same server. There are some security issues that would need to be addressed to that arbitrary files could not be read from the server.

  1. POST request https://example.execute-api.us-west-2.amazonaws.com/api/pdf?data=base64tothemoon

A fourth approach would send over PDFs (as a zip file sent as a base64 string) and send a POST request to AWS API Gateway, which would trigger the Lambda function to run, merge the PDFs together, and then send the merged PFS back in base64.

In all of these cases, info about the combined PDFs should be logged for tracking, which might affect what the request parameters might look like.

How Logging Might Function

  1. Each combination could be sent to a 3rd-party analytics provider (or event through http://segment.com and allow the actual integration to be delegated to that service). Each even could track which PDFs are combined and other data about the created file.

  2. Each combination could logged in a text file.

  3. Each combination could be written to disk permanently.

Additional questions

  • Where are generated PDFs stored, and should they be stored at all?
  • What configuration options are required? (e.g. AWS key; cover PDF path; page number placement, font, size)?

Next Immediate Steps!

(What you have been waiting for all this time)

Step 1: Run Some Spikes

Two separate spikes will be conducted, since it's been identified that the simplest option would be to use the existing front-end server and build an API in PHP, and the most interesting option would be to use AWS Lambda and API Gateway.

  • @jackjennings will take on the spike of building out an API on the existing server using PHP.
  • @skwak will take on the spike of setting up AWS API Gateway and creating an AWS Lambda function to merge PDFs.

Step 2: 🎱 Share What Was Learned & Deliberate 🎱

Implement whatever seems best out of what was learned from the above spikes 💯

Clone this wiki locally