Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
CouchDB and PHP Web Development Beginner's Guide
CouchDB and PHP Web Development Beginner's Guide

CouchDB and PHP Web Development Beginner's Guide:

eBook
$26.09 $28.99
Paperback
$48.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with Print?

Product feature icon Instant access to your digital copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Redeem a companion digital copy on all Print orders
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Table of content icon View table of contents Preview book icon Preview Book

CouchDB and PHP Web Development Beginner's Guide

Chapter 1. Introduction to CouchDB

Welcome to CouchDB and PHP Web Development Beginner's Guide. In this book, we will learn the ins and outs of building a simple but powerful website using CouchDB and PHP. For you to understand why we do certain things in CouchDB, it's first important for you to understand the history of NoSQL databases and learn CouchDB's place in database history.

In this chapter we will:

  • Go over a brief history of databases and their place in technology

  • Talk about how databases evolved into the concept of NoSQL

  • Define NoSQL databases by understanding different classifications of NoSQL databases, the CAP theorem and its avoidance of the ACID model

  • Look at the history of CouchDB and its main contributors

  • Talk about what makes CouchDB special

Let's start by looking at the evolution of databases and how NoSQL arrived on the scene.

The NoSQL database evolution

In the early 1960s, the term database was introduced to the world as a simple layer that would serve as the backbone behind information systems. The simple concept of separating applications from data was new and exciting, and it opened up possibilities for applications to become more robust. At this point, databases existed first as tape-based devices, but soon became more usable as system direct-access storage on disks.

In 1970, Edgar Codd proposed a more efficient way of storing data — the relational model. This model would also use SQL to allow the applications to find the data stored within its tables. This relational model is nearly identical to what we know as traditional relational databases today. While this model was widely accepted, it wasn't until the mid 1980s that there was hardware that could actually make effective use of it. By 1990, hardware finally caught up, and the relational model became the dominant method for storing data.

Just as in any area of technology, competition arose with Relational Database Management Systems (RDBMS) . Some examples of popular RDMBS systems are Oracle, Microsoft SQL Server, MySQL, and PostgreSQL.

As we moved past the year 2000, applications began to produce incredible amounts of data through more complex applications. Social networks entered the scene. Companies wanted to make sense of the vast amounts of data that were available. This shift brought up some serious concerns about the datastructure, scalability, and availability of data that the relational model didn't seem to handle. With the uncertainty of how to manage this large amount of ever-changing data, the term NoSQL emerged.

The term NoSQL isn't short for "no SQL;" it actually stands for "not only SQL". NoSQL databases are a group of persistent solutions, which do not follow the relational model and do not use SQL for querying. On top of that, NoSQL wasn't introduced to replace relational databases. It was introduced to complement relational databases where they fell short.

What makes NoSQL different

Besides the fact that NoSQL databases do not use SQL to query data, there are a few key characteristics of NoSQL databases. In order to understand these characteristics, we'll need to cover a lot of terminology and definitions. It's not important that you memorize or remember everything here, but it's important for you to know exactly what makes up a NoSQL database.

The first thing that makes NoSQL databases different is their data structure. There are a variety of different ways in which NoSQL databases are classified.

Classification of NoSQL databases

NoSQL databases (for the most part) fit into four main data structures:

  • Key-value stores: They save data with a unique key and a value. Their simplicity allow them to be incredibly fast and scale to enormous sizes.

  • Column stores: They are similar to relational databases, but instead of storing records, they store all of the values for a column together in a stream.

  • Document stores: They save data without it being structured in a schema, with buckets of key-value pairs inside a self-contained object. This datastructure is reminiscent of an associative array in PHP. This is where CouchDB lands on the playing field. We'll go much deeper into this topic in Chapter 3, Getting Started with CouchDB and Futon.

  • Graph databases: They store data in a flexible graph model that contains a node for each object. Nodes have properties and relationships to other nodes.

We won't go too deeply into examples of each of these types of databases, but it's important to look at the different options that are out there. By looking at databases at this level, it's relatively easy for us to see (in general) how the data will scale to size and complexity, by looking at the following screenshot:

If you look at this diagram, you'll see that I've placed a Typical Relational Database with a crude performance line. This performance line gives you a simple idea of how a database might scale in size and complexity. How is it possible that NoSQL databases perform so much better in regards to high size and complexity of data?

For the most part, NoSQL databases are scalable because they rely on distributed systems and ignore the ACID model. Let's talk through what we gain and what we give up through a distributed system, and then define the ACID model.

When talking about any distributed system (not just storage or databases), there is a concept that defines the limitations of what you can do. This is known as the CAP theorem.

CAP theorem

Eric Brewer introduced the CAP theorem in the year 2000. It states that in any distributed environment, it is impossible for it to provide three guarantees.

  • Consistency: All the servers in the system will have the same data. So, anyone using the system will get the latest data, regardless of which node they talk to in the distributed system.

  • Availability: All of the servers will always return data.

  • Partition-tolerance: The system continues to operate as a whole, even if an individual server fails or cannot be reached.

By looking at these choices, you can tell that it would definitely be ideal to have all three of these things guaranteed, but it's theoretically impossible. In the real world, each NoSQL database picks two of the three options, and usually develops some kind of process to mitigate the impact of the third, unhandled property.

We'll talk about which approach CouchDB takes shortly, but there is still a bit to learn about another concept that NoSQL databases avoid: ACID.

ACID

ACID is a set of properties that apply to database transactions, which are the core of traditional relational databases. While transactions are incredibly powerful, they are also one of the things that make reading and writing quite a bit slower in relational databases.

ACID is made up of four main properties:

  • Atomicity: This is an all or nothing approach to dealing with data. Everything in the transaction must happen successfully, or none of the changes are committed. This is a key property whenever money or currency is handled in a system, and requires a system of checks and balances.

  • Consistency: Data will only be accepted if it passes all of the validation in place on the database, such as triggers, data types, and constraints.

  • Isolation: Transactions will not affect other transactions that are occurring, and other users won't see partial results of a transaction in progress.

  • Durability: Once the data is saved, it is safe against errors, crashes, and other software malfunctions.

Again, as you read through the definition of ACID, you are probably thinking to yourself, "These are all must haves!" That may be the case, but keep in mind that most NoSQL databases do not fully employ ACID, because it's near impossible to have all of these restrictions and still have blazing fast writes to data.

So what does all of that mean?

I've given you a lot of definitions now, but let's try to wrap it together into a few simple lists. Let's talk through the advantages and disadvantages of NoSQL databases, when to use, and when to avoid NoSQL databases.

Advantages of NoSQL databases

With the introduction of NoSQL databases, there are lot of advantages:

  • You can do things that simply weren't possible with the processing and query power of traditional relational databases.

  • Your data is scalable and flexible, allowing it to scale to size and complexity faster, right out of the box.

  • There are new data models to consider. You don't have to force your data into a relational model if it doesn't make sense.

  • Writing data is blazing fast.

As you can see, there are some clear advantages of NoSQL databases, but as I mentioned before, there are still some negatives that we need to consider.

Negatives of NoSQL databases

However, along with the good, there's also some bad:

  • There are no common standards; each database does things just a little bit differently

  • Querying data does not involve the familiar SQL model to find records

  • NoSQL databases are still relatively immature and constantly evolving

  • There are new data models to consider; sometimes it can be confusing to make your data fit

  • Because a NoSQL database avoids the ACID model, there is no guarantee that all of your data will be successfully written

Some of those negatives may be pretty easy for you to stomach, except for NoSQL's avoidance of the ACID model.

When you should use NoSQL databases

Now that we have a good take on the advantages and disadvantages, let's talk about some great use cases for using NoSQL databases:

  • Applications that have a lot of writing

  • Applications where the schema and structure of the data might change

  • Large amount of unstructured or semi-structured data

  • Traditional relational databases feel restricting, and you want to try something new.

That list isn't exclusive, but there are no clear definitions on when you can use NoSQL databases. Really, you can use them for just about every project.

When you should avoid NoSQL databases

There are, however, some pretty clear areas that you should avoid when storing data in NoSQL.

  • Anything involving money or transactions. What happens if one record doesn't save correctly because of NoSQL avoidance of the ACID model or the data isn't 100 percent available because of the distributed system?

  • Business critical data or line of business applications, where missing one row of data could mean huge problems.

  • Heavily-structured data requiring functionality in a relational database.

For all of these use cases, you should really focus on using relational databases that will make sure that your data is safe and sound. Of course, you can always include NoSQL databases where it makes sense.

When choosing a database, it's important to remember that "There is no silver bullet." This phrase is used a lot when talking about technology, and it means that there is no one technology that will solve all of your problems without having any side effects or negative consequences. So choose wisely!

The NoSQL database evolution


In the early 1960s, the term database was introduced to the world as a simple layer that would serve as the backbone behind information systems. The simple concept of separating applications from data was new and exciting, and it opened up possibilities for applications to become more robust. At this point, databases existed first as tape-based devices, but soon became more usable as system direct-access storage on disks.

In 1970, Edgar Codd proposed a more efficient way of storing data — the relational model. This model would also use SQL to allow the applications to find the data stored within its tables. This relational model is nearly identical to what we know as traditional relational databases today. While this model was widely accepted, it wasn't until the mid 1980s that there was hardware that could actually make effective use of it. By 1990, hardware finally caught up, and the relational model became the dominant method for storing data.

Just as in any area of technology, competition arose with Relational Database Management Systems (RDBMS) . Some examples of popular RDMBS systems are Oracle, Microsoft SQL Server, MySQL, and PostgreSQL.

As we moved past the year 2000, applications began to produce incredible amounts of data through more complex applications. Social networks entered the scene. Companies wanted to make sense of the vast amounts of data that were available. This shift brought up some serious concerns about the datastructure, scalability, and availability of data that the relational model didn't seem to handle. With the uncertainty of how to manage this large amount of ever-changing data, the term NoSQL emerged.

The term NoSQL isn't short for "no SQL;" it actually stands for "not only SQL". NoSQL databases are a group of persistent solutions, which do not follow the relational model and do not use SQL for querying. On top of that, NoSQL wasn't introduced to replace relational databases. It was introduced to complement relational databases where they fell short.

What makes NoSQL different

Besides the fact that NoSQL databases do not use SQL to query data, there are a few key characteristics of NoSQL databases. In order to understand these characteristics, we'll need to cover a lot of terminology and definitions. It's not important that you memorize or remember everything here, but it's important for you to know exactly what makes up a NoSQL database.

The first thing that makes NoSQL databases different is their data structure. There are a variety of different ways in which NoSQL databases are classified.

Classification of NoSQL databases

NoSQL databases (for the most part) fit into four main data structures:

  • Key-value stores: They save data with a unique key and a value. Their simplicity allow them to be incredibly fast and scale to enormous sizes.

  • Column stores: They are similar to relational databases, but instead of storing records, they store all of the values for a column together in a stream.

  • Document stores: They save data without it being structured in a schema, with buckets of key-value pairs inside a self-contained object. This datastructure is reminiscent of an associative array in PHP. This is where CouchDB lands on the playing field. We'll go much deeper into this topic in Chapter 3, Getting Started with CouchDB and Futon.

  • Graph databases: They store data in a flexible graph model that contains a node for each object. Nodes have properties and relationships to other nodes.

We won't go too deeply into examples of each of these types of databases, but it's important to look at the different options that are out there. By looking at databases at this level, it's relatively easy for us to see (in general) how the data will scale to size and complexity, by looking at the following screenshot:

If you look at this diagram, you'll see that I've placed a Typical Relational Database with a crude performance line. This performance line gives you a simple idea of how a database might scale in size and complexity. How is it possible that NoSQL databases perform so much better in regards to high size and complexity of data?

For the most part, NoSQL databases are scalable because they rely on distributed systems and ignore the ACID model. Let's talk through what we gain and what we give up through a distributed system, and then define the ACID model.

When talking about any distributed system (not just storage or databases), there is a concept that defines the limitations of what you can do. This is known as the CAP theorem.

CAP theorem

Eric Brewer introduced the CAP theorem in the year 2000. It states that in any distributed environment, it is impossible for it to provide three guarantees.

  • Consistency: All the servers in the system will have the same data. So, anyone using the system will get the latest data, regardless of which node they talk to in the distributed system.

  • Availability: All of the servers will always return data.

  • Partition-tolerance: The system continues to operate as a whole, even if an individual server fails or cannot be reached.

By looking at these choices, you can tell that it would definitely be ideal to have all three of these things guaranteed, but it's theoretically impossible. In the real world, each NoSQL database picks two of the three options, and usually develops some kind of process to mitigate the impact of the third, unhandled property.

We'll talk about which approach CouchDB takes shortly, but there is still a bit to learn about another concept that NoSQL databases avoid: ACID.

ACID

ACID is a set of properties that apply to database transactions, which are the core of traditional relational databases. While transactions are incredibly powerful, they are also one of the things that make reading and writing quite a bit slower in relational databases.

ACID is made up of four main properties:

  • Atomicity: This is an all or nothing approach to dealing with data. Everything in the transaction must happen successfully, or none of the changes are committed. This is a key property whenever money or currency is handled in a system, and requires a system of checks and balances.

  • Consistency: Data will only be accepted if it passes all of the validation in place on the database, such as triggers, data types, and constraints.

  • Isolation: Transactions will not affect other transactions that are occurring, and other users won't see partial results of a transaction in progress.

  • Durability: Once the data is saved, it is safe against errors, crashes, and other software malfunctions.

Again, as you read through the definition of ACID, you are probably thinking to yourself, "These are all must haves!" That may be the case, but keep in mind that most NoSQL databases do not fully employ ACID, because it's near impossible to have all of these restrictions and still have blazing fast writes to data.

So what does all of that mean?

I've given you a lot of definitions now, but let's try to wrap it together into a few simple lists. Let's talk through the advantages and disadvantages of NoSQL databases, when to use, and when to avoid NoSQL databases.

Advantages of NoSQL databases

With the introduction of NoSQL databases, there are lot of advantages:

  • You can do things that simply weren't possible with the processing and query power of traditional relational databases.

  • Your data is scalable and flexible, allowing it to scale to size and complexity faster, right out of the box.

  • There are new data models to consider. You don't have to force your data into a relational model if it doesn't make sense.

  • Writing data is blazing fast.

As you can see, there are some clear advantages of NoSQL databases, but as I mentioned before, there are still some negatives that we need to consider.

Negatives of NoSQL databases

However, along with the good, there's also some bad:

  • There are no common standards; each database does things just a little bit differently

  • Querying data does not involve the familiar SQL model to find records

  • NoSQL databases are still relatively immature and constantly evolving

  • There are new data models to consider; sometimes it can be confusing to make your data fit

  • Because a NoSQL database avoids the ACID model, there is no guarantee that all of your data will be successfully written

Some of those negatives may be pretty easy for you to stomach, except for NoSQL's avoidance of the ACID model.

When you should use NoSQL databases

Now that we have a good take on the advantages and disadvantages, let's talk about some great use cases for using NoSQL databases:

  • Applications that have a lot of writing

  • Applications where the schema and structure of the data might change

  • Large amount of unstructured or semi-structured data

  • Traditional relational databases feel restricting, and you want to try something new.

That list isn't exclusive, but there are no clear definitions on when you can use NoSQL databases. Really, you can use them for just about every project.

When you should avoid NoSQL databases

There are, however, some pretty clear areas that you should avoid when storing data in NoSQL.

  • Anything involving money or transactions. What happens if one record doesn't save correctly because of NoSQL avoidance of the ACID model or the data isn't 100 percent available because of the distributed system?

  • Business critical data or line of business applications, where missing one row of data could mean huge problems.

  • Heavily-structured data requiring functionality in a relational database.

For all of these use cases, you should really focus on using relational databases that will make sure that your data is safe and sound. Of course, you can always include NoSQL databases where it makes sense.

When choosing a database, it's important to remember that "There is no silver bullet." This phrase is used a lot when talking about technology, and it means that there is no one technology that will solve all of your problems without having any side effects or negative consequences. So choose wisely!

Introduction to CouchDB


For this book and for a variety of my own projects and startups, I chose CouchDB. Let's take a historical look at CouchDB, then quickly touch on its approach to the CAP theorem, and its strengths and weaknesses.

The history of CouchDB

In April 2005, Damien Katz posted a blog entry about a new database engine he was working on, later to be called CouchDB, which is an acronym for Cluster Of Unreliable Commodity Hardware. Katz, a former Lotus Notes developer at IBM, was attempting to create a fault-tolerant document database in C++, but soon after, shifted to the Erlang OTP platform. As months went by, CouchDB started to evolve under the self-funding of Damien Katz, and in February 2008, it was introduced to the Apache Incubator project. Finally, in November 2008, it graduated as a top-level project.

Damien's team, CouchOne, merged with the Membase team in 2011 to form a new company called Couchbase. This company was formed to merge CouchDB and Membase into a new product, and increase the documentation and visibility for the product.

In early 2012, Couchbase announced that it would be shifting focus from facilitating CouchDB and moving to create Couchbase Server 2.0. This new database takes a different approach to the database, which meant that it would not be contributing to the CouchDB community anymore. This news was met with some distress in the CouchDB community until Cloudant stepped in.

Cloudant, the chief CouchDB hosting company and creator of BigCouch, a fault tolerant and horizontally scalable clustering frameworking built for CouchDB, announced that they would merge their changes back to CouchDB, and take on the role of continuing development of CouchDB.

In early 2012, at the time of writing, CouchDB's most major release was 1.1.1 in March 31, 2011. But CouchDB 1.2 is looking to be released just around the corner!

Defining CouchDB

According to http://couchdb.apache.org/, CouchDB can be defined as:

  • A document database server, accessible via a RESTful JSON API

  • Ad-hoc and schema-free with a flat address space

  • Distributed, featuring robust, incremental replication with bi-directional conflict detection and management

  • Query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language.

You might be able to read between the lines, but CouchDB chose availability and partial-tolerance from the CAP theorem, and focuses on eventual consistency using replication.

We could go really deep into what each of these bullet points mean, because it will take the rest of the book until we've touched on them in depth. In each chapter, we'll begin to build on top of our CouchDB knowledge until we have a fully operational application in the wild.

Summary


I hope you enjoyed this chapter and are ready to take a deep dive into really learning the ins and outs of CouchDB. Let's recap everything we learned in this chapter.

  • We talked about the history of databases and the emergence of NoSQL databases

  • We defined the advantages and disadvantages of using NoSQL

  • We looked at the definition and history of CouchDB

That's it for the history lesson. Fire up your computer. In the next chapter, we'll set everything up to develop web applications with CouchDB and PHP, and make sure that it's all set up correctly.

Left arrow icon Right arrow icon

Key benefits

  • Build and deploy a flexible Social Networking application using PHP and leveraging key features of CouchDB to do the heavy lifting
  • Explore the features and functionality of CouchDB, by taking a deep look into Documents, Views, Replication, and much more.
  • Conceptualize a lightweight PHP framework from scratch and write code that can easily port to other frameworks

Description

CouchDB is a NoSQL database which is making waves in the development world. It's the tool of choice for many PHP developers so they need to understand the robust features of CouchDB and the tools that are available to them.CouchDB and PHP Web Development Beginner's Guide will teach you the basics and fundamentals of using CouchDB within a project. You will learn how to build an application from beginning to end, learning the difference between the "quick way"ù to do things, and the "right way"ù by looking through a variety of code examples and real world scenarios. You will start with a walkthrough of setting up a sound development environment and then learn to create a variety of documents manually and programmatically. You will also learn how to manage their source control with Git and keep track of their progress. With each new concept, such as adding users and posts to your application, the author will take you through code step-by-step and explain how to use CouchDB's robust features. Finally, you will learn how to easily deploy your application and how to use simple replication to scale your application.

Who is this book for?

This book is for beginner and intermediate PHP developers interested in using CouchDB development in their projects. Advanced PHP developers will appreciate the familiarity of the PHP architecture and can easily learn how to incorporate CouchDB into their existing development experiences.

What you will learn

  • Set up a web development environment from scratch
  • Dive into CouchDB and learn how it looks at databases, documents, design documents, and views
  • Conceptualize and create a simple PHP framework from scratch that will interact directly with CouchDB
  • Create the ability for users to sign up, log in, and reset their password through our application using CouchDB
  • Allow users to create posts and leverage design documents, views, and lists to do the heavy lifting
  • Learn how to add some of the bells and whistles commonly used by modern social networks
  • Add security and deploy your application to production
  • Learn how to use CouchDB to replicate your database
Estimated delivery fee Deliver to United States

Economy delivery 10 - 13 business days

Free $6.95

Premium delivery 6 - 9 business days

$21.95
(Includes tracking information)

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Jun 22, 2012
Length: 304 pages
Edition : 1st
Language : English
ISBN-13 : 9781849513586
Languages :
Tools :

What do you get with Print?

Product feature icon Instant access to your digital copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Redeem a companion digital copy on all Print orders
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Estimated delivery fee Deliver to United States

Economy delivery 10 - 13 business days

Free $6.95

Premium delivery 6 - 9 business days

$21.95
(Includes tracking information)

Product Details

Publication date : Jun 22, 2012
Length: 304 pages
Edition : 1st
Language : English
ISBN-13 : 9781849513586
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $ 141.97
PHP and MongoDB Web Development Beginner's Guide
$48.99
CouchDB and PHP Web Development Beginner's Guide
$48.99
Responsive Web Design with HTML5 and CSS3
$43.99
Total $ 141.97 Stars icon

Table of Contents

10 Chapters
Introduction to CouchDB Chevron down icon Chevron up icon
Setting up your Development Environment Chevron down icon Chevron up icon
Getting Started with CouchDB and Futon Chevron down icon Chevron up icon
Starting your Application Chevron down icon Chevron up icon
Starting your Application
What we'll build in this book
Bones
Project setup
Time for action — creating the directories for Verge
Time for action — initializing a Git repository
Implementing basic routing
Time for action — creating our first file: index.php
Time for action — creating the .htaccess file
Time for action — hooking up our application to Bones
Time for action — creating the class structure of Bones
Time for action — creating functions to access the route on Bones creation
Time for action — creating the register function to match routes
Time for action — creating a get function in our Bones class
Time for action — creating routes for us to test against Bones
Handling layouts and views
Time for action — using constants to get the location of the working directory
Time for action — allowing Bones to store variables and the content path
Time for action — allowing our application to display a view by calling it in index.php
Time for action — creating a simple layout file
Time for action — rendering views inside of our routes
Time for action — creating views
Adding support for other HTTP methods
Time for action — retrieving the HTTP method used in a request
Time for action — altering the register to support different methods
Time for action — adding simple but powerful helpers to Bones
Adding support for complex routing
Adding support for public files
Time for action — altering .htaccess to support public files
Time for action — creating a stylesheet for the application
Publishing your code to GitHub
Get complete code from GitHub
Summary
Connecting your Application to CouchDB Chevron down icon Chevron up icon
Modeling Users Chevron down icon Chevron up icon
User Profiles and Modeling Posts Chevron down icon Chevron up icon
Using Design Documents for Views and Validation Chevron down icon Chevron up icon
Adding Bells and Whistles to your Application Chevron down icon Chevron up icon
Deploying your Application Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Full star icon Full star icon Full star icon Full star icon Half star icon 4.5
(6 Ratings)
5 star 50%
4 star 50%
3 star 0%
2 star 0%
1 star 0%
Filter icon Filter
Top Reviews

Filter reviews by




Amazon Customer Feb 15, 2014
Full star icon Full star icon Full star icon Full star icon Full star icon 5
I found this book to be a very useful tool. For anyone considering using CouchDB and PHP this is the place to start.
Amazon Verified review Amazon
Thomas Hunter II Sep 22, 2012
Full star icon Full star icon Full star icon Full star icon Full star icon 5
When I first picked up this book, I was expecting a boring, text-book approach to code examples for PHP talking with CouchDB. Boy was I wrong. What I found was a book that has you build a complete working application. And by complete, I mean you'll add the Twitter Bootstrap framework and it will be sexy. You'll do things the hard way, and refactor with an easier method. You'll be building a PHP framework with controllers and views. You'll be integrating a third party library for communicating with CouchDB which follows a similar simplistic approach as the framework. You'll also be keeping track of everything in GIT and committing to GitHub. These are all very important things for any application developer to know, and this book will get you into some good habits.The book starts off with an introduction to general NoSQL concepts (schema-less, fast), as well as the history of database systems. It then gets into the history of CouchDB itself. Nothing in there was too surprising, however the author did put a larger emphasis on the lack of ACID compliance than I have seen elsewhere (which means data isn't 100% guaranteed). This is a great thing to point out; it prevents CouchDB from being a fit for many projects (such as financial) however perfect for other projects (high traffic logging applications) and the risk and reward gradient for every application in-between.The author also guides the reader through the complete OS X setup process for getting Apache started, configuring it to work with PHP, getting the homebrew package manager working and subsequently CouchDB installed, running, and persisting between restarts. This means the beginning programmer can take on building this application without any prior knowledge of PHP development. I thought this was a great touch, it is probably the biggest thing holding back people from programming.Overall, this book does a great job explaining REST and the HTTP verbs, how those translate into their CRUD counterparts, how JSON is a great data language to be sent over the wire. Early on we use command line cURL for interacting with the CouchDB server, a slightly tedius method. I absolutely LOVE that the author had us run through cURL requests in the command line BEFORE sending us to the web-based GUI administration app, Futon. This puts a huge emphasis on exactly what kind of data is sent over the wire, something most MySQL developers, for example, will never know.In the third chapter of the book, the author has us dive into securing our CouchDB installation. This is an important topic that could have been otherwise omitted, since it isn't necessary to get an application up and running. By default, CouchDB is insecure, and many a developer may not ever realize this until something bad happens. By calling it out early on, the code doesn't need a large refactor later on to bolt-on authentication.The book has us building a simple PHP framework, named Bones by the author. Of course, we could have skipped building this framework and simply used raw PHP scripts (e.g. having .php extensions in your address bar). This would have been a bit easier for the reader to handle, and wouldn't have required the configuration of mod_rewrite in apache.conf. However, by using this framework, the reader is more likely to explore different frameworks down the road, instead of taking a simpler route. There is a small risk though that the user won't fully understand how Apache maps URI requests to the filesystem. Overall though, by having pretty URLs the completed application looks and feels like more of a solid accomplishment, bringing confidence to the reader.Another thing worth mentioning about the Bones framework is that it makes heavy use of PHPs Anonymous Functions. I personally love this method, as it feels a lot like the Node.js Express framework. PHP didn't get support for Anonymous Functions until version 5.3, which did come out a few years ago and is largely the standard. As a PHP beginner, by learning recent features of the languages, they may be more likely to grok the language than users learning from antiquated tutorials. The framework is currently hosted on GitHub, but it appears largely dead, not having been updated in a year.The author also guides the reader step-by-step through creating a GitHub account, something that can be a little scary to beginners. I used to teach a PHP meetup regularly, and getting an account setup was one of the hardest things to do (it would require an entire session). Creating an SSH key, and doing other configurations on the command line can be daunting, but it really is necessary. So many great projects are hosted on GitHub and the sooner a developer can get in the club the better. After each big milestone, the author has us committing our changes and pushing to GitHub. This is an excellent habit to get into and the author puts a good emphasis on it.When it gets time to have PHP begin communicating with CouchDB, the author has us do so using the cURL library built in to PHP. While cURL is incredibly powerful, it is very difficult for beginners to use. It is also overly verbose. It is generally not appreciated by the PHP crowd and there are many libraries (such as Requests for PHP) built to encapsulate the difficulty with a clean, Object Oriented interface. Luckily for us, the author was using cURL to show us one way of doing things (e.g. the hard way) before switching to a better solution. He soon has us install a library specifically meant for working with CouchDB called Sag, which follows the same beginner-friendly, simple methodology as the Bones framework. He also guides us through refactoring our existing code.The Bones framework soon gets an upgrade as we add a PHP autoloader to load Sag (and later the rest of our classes). The author really does a great job of "sneaking" in a lot good practices like this. Some other nice things that sneak their way in are using Gravatar for displaying users avatars, and using simple jQuery calls for making DELETE requests and fading out newly deleted items. There is also an emphasis on code refactoring and removing redundant code, and the reason we do so is explained nicely.Of course, the application we've bene building so far is not the prettiest (Times New Roman is everyones enemy after all). Thankfully, we soon add support for the Twitter Bootstrap framework. This allows us to quickly get a good looking website up with minimal HTML boilerplate code. Throughout the book we display code in the browser using normal text, then spruce it up with markup to follow Bootstrap methodologies.A lot of PHP developers start by using MySQL as their Database System. To help make the transition to a NoSQL database system easier for those developers, the author often compares a schema-less CouchDB document to an equivalent MySQL tables and relationships. The two approaches to building database management systems are quite different, so this is a helpful comparison.At the end of the book, we take out application and deploy it to some cloud services. The author has us go through the process of setting up a PHP Fog hosting account, as well as a Cloudant CouchDB hosting account, and of course getting the two to communicate. Both of these services offer free accounts, so this doesn't hold back the user. The account setup pages have screenshots for us to follow along and we are told how to get the PHP application to connect to the remote CouchDB instance. We also take our local CouchDB and have it replicate to the remote server, a nice feature which didn't have to make the cut for a beginners book.One thing that I didn't quite understand is why we used the CouchDB _users database instead of rolling our own. It could be that I'm not as familiar with CouchDB as I should be, but it seems like an application specific way would be better than a database specific method. CouchDB uses salted SHA1 password encryption, which we've seen a lot of negative press around over the past year or so. By rolling our own encryption we could have used a more secure encryption such as bcrypt.Another thing I wasn't a fan of was enabling hidden files in Finder. Personally, I would have had the users use the `ls` command in terminal, and mention that there are hidden files that aren't normally shown in Finder. For editing the config files, we could have used the `mate` command provided with Textmate (the text editor the author suggests). By using the command line more it might have made the reader a little more comfortable with it. Thankfully the author does provide a command to disable hidden files once we're done.Overall, CouchDB and PHP Web Development Beginner's Guide is an amazing book for any beginner looking to get into building PHP applications to persist data using CouchDB. There are many good practices sprinkled into the pages within. Anyone running a computer with OS X can follow along, even if they have no prior experience with programming or databases. The verbose code explanations do a great job explaining what the author is having us build. If you are interested in either of these technologies I highly recommend picking up this book.
Amazon Verified review Amazon
Brent Eyler Jun 25, 2012
Full star icon Full star icon Full star icon Full star icon Full star icon 5
The author does a terrific job complementing the learning with actual coding to reinforce what I'm reading. Really enjoying it and recommend for anyone seeking to learn CouchDB with PHP
Amazon Verified review Amazon
Dave Poon Sep 25, 2012
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
Recently I have been researching about NoSQL, I was looking for a NoSQL database to add more capability to one of my web applications. And I heard something good about CouchDB, I went to the CouchDB official website, I had a quick read at the documentation, however, there're not much tutorials and books about CouchDB and PHP until this book CouchDB and PHP Web Development Beginner's Guide has been published. I found this book is a great resource for learning how the CouchDB and PHP work for web development.The hands-on tutorial writing style that make complicated concept easier to understand, we just need to follow every step, we will discover and learn more through each step. The great thing is not just follow the steps, the author also explain "What Just Happened" for each step that have done. This make me easier to understand the code better, not like some books, we just follow and put the code, run it, it's work, and no explanation about what just happened about the example codes.One of the best parts that I really like is the author teaches you to create a PHP MVC framework called "Bones framework" with CouchDB database, this book teach you how to build a best practices PHP and CouchDB web application from scratch. The author also inform us to use Git (version control system) to commit your code once you have done the changes to your code. This is a great practice to use version control system to keep track of your source code while developing our application. I am really impressed with details like this, it's not just teach you one thing, and forget the others, the author also teach you good programming practice when building a PHP and CouchDB web application.This is the beginner's guide series of the book, however, this book is not easy for beginner to understand. You need or recommend to have experience in object oriented PHP programming, and understand what MVC Model-View-Controller design pattern is, and also have experience using command line for basic system operations.
Amazon Verified review Amazon
Raistrick Jul 27, 2012
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
I like the way this book is written. Software books are always nice when you can be taken on a journey through learning (provided you have the time) and this book takes time to introduce you to lots of techniques and tools that will make CouchDB development easier and more organised. For someone wanting to swap an SQL database for a NoSQL database, whilst keeping the server-side programming consistent with previous methods, then this book is great. I'm looking to do this so that the site and data management can be kept separate and take some of the load off the CouchDB developer. However, at the rate that these technologies are changing, along with the errors you are likely to encounter developing anything in CouchDB, you'll find the IRC channel and stackoverflow far more use.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is the digital copy I get with my Print order? Chevron down icon Chevron up icon

When you buy any Print edition of our Books, you can redeem (for free) the eBook edition of the Print Book you’ve purchased. This gives you instant access to your book when you make an order via PDF, EPUB or our online Reader experience.

What is the delivery time and cost of print book? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
What is custom duty/charge? Chevron down icon Chevron up icon

Customs duty are charges levied on goods when they cross international borders. It is a tax that is imposed on imported goods. These duties are charged by special authorities and bodies created by local governments and are meant to protect local industries, economies, and businesses.

Do I have to pay customs charges for the print book order? Chevron down icon Chevron up icon

The orders shipped to the countries that are listed under EU27 will not bear custom charges. They are paid by Packt as part of the order.

List of EU27 countries: www.gov.uk/eu-eea:

A custom duty or localized taxes may be applicable on the shipment and would be charged by the recipient country outside of the EU27 which should be paid by the customer and these duties are not included in the shipping charges been charged on the order.

How do I know my custom duty charges? Chevron down icon Chevron up icon

The amount of duty payable varies greatly depending on the imported goods, the country of origin and several other factors like the total invoice amount or dimensions like weight, and other such criteria applicable in your country.

For example:

  • If you live in Mexico, and the declared value of your ordered items is over $ 50, for you to receive a package, you will have to pay additional import tax of 19% which will be $ 9.50 to the courier service.
  • Whereas if you live in Turkey, and the declared value of your ordered items is over € 22, for you to receive a package, you will have to pay additional import tax of 18% which will be € 3.96 to the courier service.
How can I cancel my order? Chevron down icon Chevron up icon

Cancellation Policy for Published Printed Books:

You can cancel any order within 1 hour of placing the order. Simply contact customercare@packt.com with your order details or payment transaction id. If your order has already started the shipment process, we will do our best to stop it. However, if it is already on the way to you then when you receive it, you can contact us at customercare@packt.com using the returns and refund process.

Please understand that Packt Publishing cannot provide refunds or cancel any order except for the cases described in our Return Policy (i.e. Packt Publishing agrees to replace your printed book because it arrives damaged or material defect in book), Packt Publishing will not accept returns.

What is your returns and refunds policy? Chevron down icon Chevron up icon

Return Policy:

We want you to be happy with your purchase from Packtpub.com. We will not hassle you with returning print books to us. If the print book you receive from us is incorrect, damaged, doesn't work or is unacceptably late, please contact Customer Relations Team on customercare@packt.com with the order number and issue details as explained below:

  1. If you ordered (eBook, Video or Print Book) incorrectly or accidentally, please contact Customer Relations Team on customercare@packt.com within one hour of placing the order and we will replace/refund you the item cost.
  2. Sadly, if your eBook or Video file is faulty or a fault occurs during the eBook or Video being made available to you, i.e. during download then you should contact Customer Relations Team within 14 days of purchase on customercare@packt.com who will be able to resolve this issue for you.
  3. You will have a choice of replacement or refund of the problem items.(damaged, defective or incorrect)
  4. Once Customer Care Team confirms that you will be refunded, you should receive the refund within 10 to 12 working days.
  5. If you are only requesting a refund of one book from a multiple order, then we will refund you the appropriate single item.
  6. Where the items were shipped under a free shipping offer, there will be no shipping costs to refund.

On the off chance your printed book arrives damaged, with book material defect, contact our Customer Relation Team on customercare@packt.com within 14 days of receipt of the book with appropriate evidence of damage and we will work with you to secure a replacement copy, if necessary. Please note that each printed book you order from us is individually made by Packt's professional book-printing partner which is on a print-on-demand basis.

What tax is charged? Chevron down icon Chevron up icon

Currently, no tax is charged on the purchase of any print book (subject to change based on the laws and regulations). A localized VAT fee is charged only to our European and UK customers on eBooks, Video and subscriptions that they buy. GST is charged to Indian customers for eBooks and video purchases.

What payment methods can I use? Chevron down icon Chevron up icon

You can pay with the following card types:

  1. Visa Debit
  2. Visa Credit
  3. MasterCard
  4. PayPal
What is the delivery time and cost of print books? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
Modal Close icon
Modal Close icon