Share Your Salary App Part 3

So in Part 1 we built the core classes for our app and we exposed those classes as a RESTful web service in Part 2. Now, we’ll build a UI and wrap up the project.

Feel free to check out the application first or pull up the source in another window.

Demo Source on GitHub

The Fat Free Framework configuration allows you to specify a document root for the front-end pages. By default, this is set to the ‘ui’ directory in the root of the F3 directory structure. This will be our working directory for building the UI. The F3 package will have a few pages, CSS, and images in the ‘ui’ directory, you can delete them all if you want (I kept the welcome.htm file just out of convenience).

Now I’m not a good UI developer, so I tend to use the Bootstrap framework (v2.3.2) for the front-end of my applications. Go ahead and download the Bootstrap package and unzip it in the ‘ui’ directory. The ‘ui’ directory structure should look like this:

  • ui/
    • js/
      • bootstrap.js
      • bootstrap.min.js
      • jquery.js
    • css/
      • base.css
      • bootstrap-responsive.css
      • bootstrap-responsive.min.css
      • bootstrap.css
      • bootstrap.min.css
      • theme.css
    • img/
      • glyphicons-halflings-white.png
      • glyphicons-halflings.png
    • welcome.htm (from the f3 package)

Now we have the components that we need to start building pages. Let’s start by building a layout.htm file – this will be the base HTML file (with a common header, footer, styles and script tags) that will be populated with content for each page. These types of pages/files are referred to as templates.

Read more

Share Your Salary App Part 2

In Part 1, I covered the core classes for the Share Your Salary application. These classes covered my Model and Controllers in my quasi-MVC application. Now we’re ready to expose those controller functions via a RESTful API.

For this project, I used the Fat Free Framework for both API routes and web page templating. To start, I simply downloaded and unzipped the F3 package and added the contents to my shareyoursalary app directory. Next, I created a “classes” folder and added the PHP class files I created in Part 1. At this point, my folder structure looked like this:

  • shareyoursalary/
    • classes/
      • database.php
      • survey.php
    • config.ini
    • lib/
    • .htaccess
    • index.php
    • readme.md
    • ui/
      • css/
      • images/
      • layout.htm
      • userref.htm
      • welcome.htm

Now to create the API functionality, I created routes in F3. F3 makes it really easy to make HTTP method-specific routes that then map to pages, classes, or specific functions. In my case, I wanted to create routes for the various functions I created in the Survey class. To do this, we’ll need to edit the index.php file in the root of the F3 directory. I left the existing code as-is, and added the following lines:

As you can see, the route syntax is:
‘METHOD /URL/PATH/@parameter’, ‘Class->functionName’.

RESTful APIs should use certain methods based on what you’re doing to the object (e.g. if you’re reading an object, use GET, if you’re creating an object, use POST). Here’s a quick breakdown for reference:

GET – Reading an object
POST – Creating a new object (or overwriting an entire object)
PUT – Updating attributes of an existing object (this should be an idempotent operation)
DELETE – I’ll give you three guesses.

There are other methods, but these are the four main methods you’ll encounter with APIs.

Read more

Share Your Salary App Part 1

In a previous project, I built “Who’s that person in that thing?,” a JavaScript web app that called The Movie DB’s API to find common actors given two movies. That was fun, but I still wanted to build an API service myself and I wanted to experiment with some new tools. But first I needed a project idea as an excuse to use them.

Project Idea/Application Premise/The Excuse

People are funny about money, especially about their salary. With most people, it’s a taboo to talk about it. But everyone’s been curious at some point to know how they compare to their peers. Some people fear they are getting paid less to do the same work as others, and sometimes that fear is founded in fact. The “Share Your Salary” app is an anonymous salary survey tool to address these kinds of use cases.

Before we get into any of the tools or how-to, feel free to check out the application first or look over the source.

Demo Source on GitHub

New Tools

OpenShift

Well I started to write this section, turned out to be about a thousand words… so I moved it to it’s own separate post. In short, OpenShift is a PaaS hosting service. OpenShift hosts the entire Share Your Salary app, including a MongoDB container, an HAProxy load balancer, and Apache/PHP containers in an auto-scaling group.

MongoDB

MongoDB is a highly scalable NoSQL database. MongoDB is a document database and uses JavaScript Object Notation (JSON) to represent those documents. I really like JSON, but PHP doesn’t ‘speak’ JSON natively, which makes using MongoDB a little less intuitive. I wrote a separate MongoDB and PHP Primer post to go over some of the basics.

I used MongoDB as the backend for the “Share Your Salary” app.

Fat Free Framework

Fat Free Framework (or F3 for short) is a tiny PHP framework (it’s only ~65 KB in total) that provides URL routing, caching, page templating, and built-in database support for MySQL, SQLite, MSSQL/Sybase, PostgreSQL, MongoDB and F3’s proprietary flat-file DB called Jig.

I used F3 for both templating web front-end as well as the API.

Swagger UI

Swagger UI is a must if you are building a RESTful API service – it acts as both a documentation method and a test bed. As the developer, you complete a JSON file that describes your API routes, methods, parameters, etc. Swagger UI transforms that JSON into a web page and API client that uses JavaScript to send HTTP GET/POST/PUT/DELETE requests to your API service and displays the results. Check out the Swagger Petstore Demo.

Read more

MongoDB and PHP Primer

I recently used MongoDB in the Share Your Salary app and had a few hiccups as I tried to blunder my way through learning how to use it. MongoDB, like many NoSQL document databases, uses JavaScript Object Notation or JSON to represent the objects/documents. JSON is great, especially when you’re using JavaScript in conjunction. PHP, however, doesn’t ‘speak’ JSON natively; it uses arrays instead, and this makes for some less than intuitive interactions. This post will go over some of the basic CRUD operations using PHP against a MongoDB.

Connecting

Connecting is pretty straight-forward:

If you’re using OpenShift, you can simply use the relevant environment variables:

Read more

Introduction to OpenShift

OpenShift is a Platform-as-a-Service offering provided by Red Hat. It’s built on top of Linux containers (which they refer to as ‘gears’) hosted in Amazon’s Amazon Web Services (AWS). They offer many different platforms such as PHP/Apache, JBoss, Tomcat, NodeJS, Python, Ruby-on-Rails, and many more. OpenShift refers to these pre-built platforms as ‘cartridges.’

Beyond the platforms they offer, OpenShift also takes care of DNS (you are given a *.rhcloud.com subdomain), load balancing via HAProxy, and auto-scaling for your application. Much like Heroku, code deployment is as easy as executing a git push. All of these features, including 3 containers, are all free of charge.

Red Hat has done a good job making OpenShift “cloudy” – for example, database connection strings are handled by environment variables. This is cloud-friendly because:

  1. Your source code can now reference the environment variables instead of storing credentials in your source (preventing you from using public repositories) or having a separate private deployment repository with credentials that you have to manage.
  2. Your source code can now be deployed instantly in another OpenShift environment, no need to change credentials in the code.
  3. You don’t have to worry about passing credentials to new instances during auto-scaling, OpenShift takes care of it for you.
  4. Your application and operations folks can deploy and manage your application without them having access to the database credentials.

This is just one example but I think it does a good job illustrating the foresight Red Hat had when they built OpenShift.

If you’re a developer and don’t want to worry about the infrastructure details yet, OpenShift is really an amazing service. You can set up an application in just a few minutes, I’ll show you how. Let’s get started.

Continue to the setup instructions

1 2 3 9