First login?
Lost password?
 
 
 
General mailing list for discussions and development of PeerLibrary and related software.

List archive Help


Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries


Chronological Thread 
  • From: Mitar < >
  • To:
  • Subject: Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries
  • Date: Wed, 06 Aug 2014 14:46:52 +0100
Hi!

> I've been using REST APIs for a while. With such an API, it's very
> simple to make an ad hoc query: you start an HTTP request and feed the
> answer into your model/collection (which is rendered).
>
> How's the corresponding work flow for an ad hoc query with
> Meteor/PeerDB? For example: how would you implement a search of Persons
> with a given name?
>
> The code you mentioned for the publication search is >200 lines and
> appears to be very complex (given the quite simple task). I really hope
> that Meteor provides an easier way for implementing a simple ad hoc
> Person search. :)

It is quite different. Imagine it like that. You federate part of the
database with the client and then you do MongoDB queries directly on the
client. So the complicated question is only: which documents you
federate with the client, and which fields inside those documents (you
can limit to only subset).

So you can push everything and then simply do MongoDB queries whichever
you want.

You see >200 lines of code because you are looking at full-text search.
Not at normal MongoDB queries. And yes, full-text is a bit more
complicated, especially if you want to support reactivity, permissions,
and (not yet added) ElasticSearch backend.

We also wanted to optimize which documents we are sending, to minimize
data. So then instead of sending many documents over and filtering on
the client, we send only the relevant documents.

Instead of you doing one REST request, you subscribe to data and then
you get initial copy of data + all future changes are pushed to this. In
this way your client copy of data keeps in sync with the server.

Moreover, Meteor provides a very simple and clean API on which you build
stuff. So the code is not >200 lines, but 29 lines:

https://github.com/peerlibrary/peerlibrary/blob/development/server/person.coffee#L117

You are the first person complaining about Meteor not providing enough.
:-) Most people complain that it is too opinionated framework and that
it locks you too much into their way of doing. So Meteor provides a very
simple and elegant API for federating data between server and client. On
top of that we implemented few things. And now I think things are quite
nice. Of course if you look into all the implementation for all of this
is it takes quite some code, and maybe it is just a little undocumented. ;-)

> Aren't global variables the root of all evil? ;) They definitely make
> the code unstructured and hard to read...

They are very limited. Meteor provides namespacing for packages and a
limited number of variables they export (like Document variable exported
by our package PeerDB). I am not sure if they make it unstructured and
hard to read? Maybe if you are not used to them? We have them documented
as well:

https://github.com/peerlibrary/peerlibrary/wiki/Entities

So yes, they are evil, but they can also be seen as an internal API to
talk between various parts of the code. So those which are made global,
are limited and used as internal API (so you also have some contract how
they behave and should be wary about changing them).

CoffeeScript has file-scope for top-level variables in a file. So you
really have to explicitly make a variable global.

Do you have any suggestions how we would do things differently?


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Archive powered by MHonArc 2.6.18.

Top of page