Searching on Appacitive. Part 2

Hey, welcome back ! In this tutorial we are gonna take a look at some of the more advanced searching techniques in the Appacitive API.

Article Search

I. The in-between query -
{articleAId} is an article of SchemaA and {articleCId} is an article of SchemaC. This query would return articles of SchemaB that fulfill the given scenario. i.e. have connections to articles of SchemaA and SchemaC of type RelationAB and RelationBC respectively.

As a real world example, consider schemas hotels, visitors and reviews. Visitors visit hotels and some of them write reviews about their visits. SchemaA is hotels and SchemaC is visitirs. We want articles of reviews (SchemaB) where we provide the hotel and the visitor and their corresponding labels.

Connection Search

I. The find connections for articles query -
In this query you provide two articles of same or different schemas and all connections between those two articles are returned. Also if you optionally provide a `relatiotype` as a query string parameter with the name or id of a relation as its value, you will get back just the connections of that relation type between those two articles.

a. Connections of all relations

b. Connections of a specefic relation
GET{articleId1}/{articleId2}?relationtype={relation name or id}

II. The find connected articles query -
In this search, you provide a relation type (name or id) and an articleId and what is returned are two lists, one of all the connections belonging to the above mentioned relation whose one endpoint is the above mentioned article and also all the other article ids that are on the opposite end of these connections.
Such queries come helpful in a situation where you want to know all the interactions of a specefic kind for of a particular article in the system. For example if I want to know all the hotels a visitor has ever visited and also details of all the visits, I would use this query.
GET{relation name or id}/{articleId}/find

III. The interconnects query -
This query is a POST call with its body containing two parts. The first part is a single article Id and the other part is a list of article Ids. What this query returns is a paginated list of all connections between the single article id and any of the article ids in the list. For example if you just wanted to know the visits of a visitor for a single chain of hotels, you would pass the visitor article id as the single article id and the hotel ids as the list of article ids.
“article1id”: “1″,
“article2ids”: [
This would return all connections with artcle id 1 on one side and 2,3 or 4 on the other side.

Graph Query 

This is one of the most powerful query features in the Appacitive API.
<coming soon>

Searching on Appacitive. Part 1

Hi, in this blog I will describe the basics of searching for articles and connections. Appacitive keeps your data indexed and cached so as to provide real-time searching and mining.

Articles/Connection Searches -
Articles are instances of schemas and hold values in their properties, properties which are described by their parent schemas. Conversely, connections are instances of relations and also hold property values as specified in their parent relations. For example, in a social network model, a schema could be Persons and articles for schema Persons would be you and me. We would have properties to describe us like name, gender, display picture, favourites, hobbies, last checkin, date of birth etc. And there could be a relation called friends with the schema Person on both ends depicting a friend relationship between two persons.

Other schemas could be other objects in the system like songs, movies or recipes. You could have a connection with a movie which would have properties like the date you watched the movie and the rating you gave it. You could also have a connection with a song describing when you heard it and what rating you gave it. Here is the model we will use in this tutorial to understand the search API(s).

Now consider you have this model and have lots of people signed in and also have a considerable amount of data. Now coming to searching for articles/connections for your application. First come the filter queries.

Query filters are passed in the URL as Query String Parameters. Search calls are HTTP GET calls with two headers, Appacitive-Session and Appacitive-Environment.
These searches are the same for both articles and connections.

I. The basic search -
Now if you wanted a paginated list of all the movies (all articles of schema movies) in the system ordered by their release date,

II. The filter search -
Additional filters are applied by passing a filter query on `properties`, `attributes` and `aggregates` in a query string parameter called `query`.

Property names are prefixed with ‘*’.
Attribute names are prefixed with ‘@’.
Aggregate names are prefixed with ‘$’.

If you wanted all love stories before 1970
GET*genre == ‘love story’ and *release_date < date(’1970-12-12′)

If you want all movies which contains the word ‘love’ in its name and attribute with key ‘opening’ and value ‘blockbuster’.
GET*name like ‘*love*’ and @opening == ‘blockbuster’

This way you can create your desired query using and/or and >,<,==,<= and >=.
Date, time and datetime values need to be cast into types they are being compared with like date(’1970-12-12′) or datetime(’1964-12-11T00:00:00.0000000′)

III. The free-text search
As all your data is indexed you can fire free-text queries on any textual property in your model.
If you wanted all songs with the words ‘rock’ and ‘roll’ in their lyrics
GET roll&language=english

IV. The tags search
As all articles (and connections) contain tags, which are also kept indexed in memory, you can fire queries on tags along with other parameters. There are two kinds of queries on tags.

a. Tagged with one or more – returns articles which have at least one of the specified tags.
GET (‘rock pop trance’)

b. Tagged with all – returns articles tagged with all the specified tags.
GET (‘rock 1969 woodstock’)

V. The between search
You can provide min and max range values and retrieve values which fall between them. Such between searches can be fired on numeric (long,decimal) and chronological properties (date,time and datetime).

For example if you wanted to retrieve all music albums from the 1960′s which cost between $5 and $15.
GET*release_date between (date(’1960-01-01′) date(’1970-12-12′) ) and *price between (5 15)

VI. The geographical search
Appacitive understands geo coordinates in the form of a longitude and latitude which can be used to perform spatial searches of two types.

a. Radial search – For when you are hunting for articles around you with you as the centre and a predetermined radius.
Say you are at (10.10,20.20) and are looking for articles (other users) in a 100 mile radius.
GET*current_location within_circle 10.10,20.20,100 mi)
Possible metrics for radial distance are ‘mi’ or ‘miles’ for miles and ‘km’ for kilometer.

b. Polygon search – When you are hunting for articles inside a ploygon. You need to provide the coordinates of three vertices. Say the three vertices are (0,0), (10,0), (0,10).
GET*current_location within_polygon 0,0 | 10,0 | 0,10)

These are the possible searches that can be performed on articles and connections.

Important : Additionally you can mention in your query (or any GET call) exactly which all fields you want returned so as to reduce payload. The query string parameter is `fields`.

This was the basic querying DSL. The next tutorial will aim to explain the more advanced searching techniques.


Getting Started with Appacitive

Hi, if you are reading this I assume you are new to the Appacitive ecosystem. This tutorial will get you started with the absolute basics of the platform. You design your backend infrastrucure to hold your data for which the visual modelling tool is a great accessory.
The basic building blocks of your application’s backend are schemas, articles, relations, connections and canned lists.

Schemas -
You can visualize schemas as tables in a contemporary relational database. It has properties which hold values for that schema just like columns for a table. A property has a data type and additional constraints are configured according to your application’s need.

Data types -
The possible data types are string, text, bool, long, decimal, date, time, datetime,geography, blob and cannedlist item. Blob data type is used to store binary data such as pictures, videos or files of any format and extension. I will come back to cannedlist item towards the end.

Additional constraints -
These include range, regex, mandatory, unique, immutable, minimum length, maximum length, default value, hashing, masking and multi-valued. Ranges are applied to constrict the max, min (or both) values for a numeric or chronological property. You can make sure string properties pass your custom regex checks or one of the regexes provided out of the box. Immutable property values cannot be altered later once set. Masking is great for fields like credit card numbers where you just want to expose a subset of the value and hashing is used for properties like passwords. Your specified default values get stored for a property in the absense on one if configured so.

Articles -
Articles can be thought of as rows in the table or instances of a class. An article of a schema contains values for its schema’s properties where each property value obeys the rules defined by its parent schema for it. Each article has a unique id assigned to it. Appacitive offers an extensive seach engine to mine articles(and connections) for your app’s businness and analytical needs.As an example, if there was a schema called Players to model players of a sport, then articles for that schema would be individual players you entered into the system.

Relations -
A relation is used to model a relationship between two schemas. a typical example could be a relation called contract between schemas player and team. A relation has properties of its own which have data types and applicable constraints like in the case of schemas. A relation mentions the two schemas it connects and the multiplicity for both sides. You can configure it so that a player can belong to just one team but a team can have multiple(or n) players.

Connections -
Connections for a relation are instances for that relation and hold values in properties for its parent relation. You create a connection to connect two articles together and hold values for that relation. These values are for the relation properties and obey the rules defined by the parent relation.

Canned Lists -
A canned list is a list of key value pairs. They are used to force the value of a property to come from a list of predefined items. Don’t get confused, but a canned list can also have dynamic values you can configure to come from an external source. A typical example could be a canned list of airports. A property can be configured to hold a value coming only from this list. It can be assumed to be a pointer to a key value pair from the canned list.

So, that was a brief overview of the general blocks and nomenclature for the platform. Have fun building kick-ass apps using the Appacitive system.

Tagged under:

Why would you need a mobile backend as a service platform ?

Why would you need a mobile backend as a service platform?

To understand the need for a mobile backend as a service (MBaas) platform, one needs to analyse the anatomy of mobile or web apps  - rich device or browser hosted user interfaces collecting user interaction and translating it to data sent out to a remote server for storage and processing. Be it a game sending high scores to a global leader board or a simple todo app tracking daily tasks, the general theme is the same.

This means that as an app developer, one has to not only build an app front end, but also build a remote api backend which the app can interact with. However, there are a number of reasons why this can be particularly difficult when building mobile and web apps.

1. Rinse and repeat – Given the intense competition, the pace of development for mobile apps is hectic. There is no time for build scalable and well architected backends.

2. Short app lifetime – Market research indicates that the average life of an app is less than 30 days. This means within 30 days or less of a hectic app development schedule, most developers need to do all of the same thing, all over again.

3. Fragmented technology – There is wide disparity between the technology used to build the front-end for an app (iOS, android, html5) and the backend api(.net, python, ruby etc). Find app developers with all the required skills is not only difficult but expensive.

4. Scale – While cloud technology has matured quite a lot today, the sheer number of options available to developers can be confusing.

Apart from all this, there are more disruptive developments imminent with technology like the new Firefox mobile OS in the offing. Apps for the Firefox OS will be written completely in HTML5 and Javascript. This means that soon, every web developer out there will suddenly also become an app developer. And all if not most of them, will need a backend platform which unfortunately will not be written using just html or javascript.

This is where an MBaas platform proves invaluable. From a front-end developer’s perspective, an MBaaS platform cuts out the worst parts of build a mobile app. It shields the developer from all the nuances of building and maintaining a scalable backend, while allowing full freedom over all the data that is generated and consumed by his app. Easy to use APIs and SDKs ensure that the developer can leverage the full power of a server side backend without stepping out of the comforts of this ecosystem.