Skip to content
This repository was 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 13, 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)

There are two server and language options for the API:

  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.
  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.

What the Future (of Superglue) Could Look Like

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)

Other Combining-PDF-Examples

How the API Might Function

Here are two possible approaches:

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

    The 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)

The 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.

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

Clone this wiki locally