Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local JSON support related #48

Closed
gliechtenstein opened this Issue Nov 14, 2016 · 22 comments

Comments

Projects
None yet
@gliechtenstein
Copy link
Contributor

gliechtenstein commented Nov 14, 2016

Some people have requested local JSON feature. I have some concerns on this. But I also see some benefits. And overall, I think it's worth discussing.

Possible solutions

There can be two solutions to this:

Approach 1. OPEN THE FILE DIRECTLY

Just use the internal method to directly open a JSON file from the bundle and draw it to the view.

Approach 2. SET UP AN IN-APP WEB SERVER

Set up an in-app web server and serve local files through the web server. (You could access them using something like local:// or localhost:// or something like that) This may sound convoluted compared to Approach 1, but I think it's interesting in its own way. More on this below.

Current status

There have been a couple of pull requests for this. I took a look at them and categorized them into these categories:

  1. Approach 1

  2. Approach 2

Benefits

The obvious benefit is you can run your app offline. This is great, and some people have asked for this. Also you can quickly develop locally if you have a local JSON.

Concerns

My concern is just that I wasn't envisioning this kind of usage when I was building Jasonette. It may look like just an innocent little feature, but I think it may have larger implication than that, going forward.

Until now Jasonette has been fully cloud based, therefore easy to understand--You simply add a URL and you have an app.

However once we support this, we have no reason not to support all kinds of other offline features. So it's not just a matter of "let's add this little feature", we will need to commit to this direction. With the current thin client approach, we can easily scale to other platforms since everything is cloud based, but starting to support local may mean this may be difficult. (Then again, even desktop web browsers have localhost features, so maybe it's workable, i don't know) But this is just my opinion based on my gut feeling. That's why I would love to hear thoughts.

Questions & Discussion

  1. I do think we may need to support this local feature at some point. It's just a matter of whether we should do it now or not. What are your thoughts on "support local now" vs. "think about it later"? Maybe it's worth a try to support it now and see how it goes?

  2. The web server approach by @copongcopong caught my interest because this feels like it could enable many other types of usage for Jasonette. Serving local files is just one usage, but what excites me is when you have a web server running, you can serve to the outside world as well. I like to imagine things so I could think of some weird and exciting use cases. I don't know yet what this would mean but I feel like there's something there. Any thoughts on this?

@thedumbtechguy

This comment has been minimized.

Copy link

thedumbtechguy commented Nov 14, 2016

I'd go with the local file (Approach 1).

A webserver is overkill and a waste of battery and resources.

On Mon, Nov 14, 2016 at 6:02 PM, gliechtenstein notifications@github.com
wrote:

Some people have requested local JSON feature. I have some concerns on
this. But I also see some benefits. And overall, I think it's worth
discussing.
Possible solutions

There can be two solutions to this:
Approach 1. OPEN THE FILE DIRECTLY

Just use the internal method to directly open a JSON file from the bundle
and draw it to the view.
Approach 2. SET UP AN IN-APP WEB SERVER

Set up an in-app web server and serve local files through the web server.
(You could access them using something like local:// or localhost:// or
something like that) This may sound convoluted compared to Approach 1, but
I think it's interesting in its own way. More on this below.
Current status

There have been a couple of pull requests for this. I took a look at them
and categorized them into these categories:

Approach 1

Benefits

The obvious benefit is you can run your app offline. This is great, and
some people have asked for this. Also you can quickly develop locally if
you have a local JSON.
Concerns

My concern is just that I wasn't envisioning this kind of usage when I was
building Jasonette. It may look like just an innocent little feature, but I
think it may have larger implication than that, going forward.

Until now Jasonette has been fully cloud based, therefore easy to
understand--You simply add a URL and you have an app.

However once we support this, we have no reason not to support all kinds
of other offline features. So it's not just a matter of "let's add this
little feature", we will need to commit to this direction. With the current
thin client approach, we can easily scale to other platforms since
everything is cloud based, but starting to support local may mean this may
be difficult. (Then again, even desktop web browsers have localhost
features, so maybe it's workable, i don't know) But this is just my opinion
based on my gut feeling. That's why I would love to hear thoughts.
Questions & Discussion

I do think we may need to support this local feature at some point.
It's just a matter of whether we should do it now or not. What are your
thoughts on "support local now" vs. "think about it later"? Maybe it's
worth a try to support it now and see how it goes?
2.

The web server approach by @copongcopong
https://github.com/copongcopong caught my interest because this
feels like it could enable many other types of usage for Jasonette. Serving
local files is just one usage, but what excites me is when you have a web
server running, you can serve to the outside world as well. I like
to imagine things so I could think of some weird and exciting use cases. I
don't know yet what this would mean but I feel like there's something
there. Any thoughts on this?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#48, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4XZV8AImpdimJe5P8EbRy4a0DqGACXks5q-KIcgaJpZM4Kxns1
.

Regards,
Stefan Froelich.

@WenchaoD

This comment has been minimized.

Copy link
Contributor

WenchaoD commented Nov 14, 2016

I can see your concern @gliechtenstein and would like to join the discussion. But what I supposed is not "support local JSON", it's "support _convenient debugging of remote JSON_". The idea of "cloud based application" keeps unchanged and shouldn't be disobeyed.

@gtramontina

This comment has been minimized.

Copy link

gtramontina commented Nov 14, 2016

It seems to me that there's an urge for an "offline-first" approach, just like what's happening with the web. Perhaps looking into what it takes to build an offline-first web app can shed some more light – or raise even more questions. 😄

In any case, this might be a good start: https://github.com/pazguille/offline-first

@jdrydn

This comment has been minimized.

Copy link

jdrydn commented Nov 16, 2016

Why not implement offline-caching?

  • If an Internet connection is available, fetch the JSON at the URL and cache the file
  • Else if we have a cached file (from an earlier run) then use that
  • Else use an offline version in the app

This requires people to either include "the latest version of the JSON file" in their app during app-updates or leave a pre-written JSON file with a "Sorry please go online" view. Either way, I think this sticks to the original principles 😉

@jereze

This comment has been minimized.

Copy link

jereze commented Nov 16, 2016

I totally agree with @jdrydn's suggestion.
I was thinking about that yesterday (opening my app designed with jasonnette in an elevator... bad connection... white page... 😞 )

@thomasbarwanitz

This comment has been minimized.

Copy link

thomasbarwanitz commented Nov 16, 2016

Am Mittwoch, 16. November 2016 schrieb Jeremy Greze :

I totally agree with @jdrydn https://github.com/jdrydn's suggestion.
I was thinking about that yesterday (opening my app designed with
jasonnette in an elevator... bad connection... white page... 😞 )


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#48 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHj4JkWLZlTLbxaJ942oLL3J5k8ZqvlRks5q-3BrgaJpZM4Kxns1
.

null

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Nov 17, 2016

@jdrydn @jereze Today's your lucky day guys. Try adding {"offline": "true"} to head:

{
  "$jason": {
    "head": {
      "offline": "true"
    }
  }
}

This is one of those undocumented features I didn't have enough time to test so didn't add to the documentation but actually works fine.

Please try it out and let us know :)

@cpg

This comment has been minimized.

Copy link
Contributor

cpg commented Nov 17, 2016

What does this feature do exactly?

Is there any harm in enabling this offline flag it in every single page in the app?

@jereze

This comment has been minimized.

Copy link

jereze commented Nov 17, 2016

Thanks. I'm giving it a try!

@aenbacka

This comment has been minimized.

Copy link

aenbacka commented Nov 17, 2016

Another aspect with offline use is security; how to protect possible sensitive information that could be part of the JSON (e.g., REST API requests) in case it is fetched online? Adding JSON as part of the application bundle would help with this issue.

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Nov 18, 2016

@aenbacka that's a great point. I think this is a good timing to share another undocumented feature. It's called $keys and you can actually use it right now without any code change. It basically lets you store key/value pairs inside settings.plist and access them from the app.

Just like rest of the undocumented features, this was intentionally left out of the official documentation because I wasn't sure about providing this feature from the beginning and wanted to first release and see if people actually feel the need for this.

Here's an example of using the $keys notation: https://jasonbase.com/things/kXz/edit

In this case we make $oauth requests (another undocumented yet extremely powerful feature) using client_id and client_secret. If you look under settings.plist in the Jasonette Xcode project, you'll see the two corresponding empty fields. So it's not just client_id and client_secret, but basically you can add any key/value pairs there and access them through $keys notation, similar to how you use $get.

Just like you said, in this case it is necessary to protect the client_id and client_secret so others can't them and impersonate you for oauth requests.

But I think having a local JSON for this purpose (as a config file) may prove to be much more powerful than using the plist format which only supports single depth key/value pairs.

Will need to give this a serious thought.

Good catch! 👍

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Nov 18, 2016

P.S. @cpg As for the "offline": "true" feature, there's no harm in using it technically, since the offline mode first renders the cached JSON, then tries the network request, and replaces the content if and only if it succeeds. I actually have a couple of apps I use regularly using this, for example I have an offline Twitter client I use to cache the entire timeline complete with all the images so I can read them when I'm on the subway with no wifi.

That said, I didn't get to test that feature enough so didn't want to advertise it heavily.

@jdrydn

This comment has been minimized.

Copy link

jdrydn commented Nov 18, 2016

But I think having a local JSON for this purpose (as a config file) may prove to be much more powerful than using the plist format which only supports single depth key/value pairs.

@gliechtenstein: Do you mean you'd have two JSON files? One for a local config file with more depth than a key-value store, and then the rest of the application loads in as it currently does?

@superboonie

This comment has been minimized.

Copy link

superboonie commented Nov 18, 2016

In regards to JSON being more powerful than plist, maybe I am missing
something. plist supports more than single depth - in fact, the things
that JSON can support, plist should be able to as well.

On Fri, Nov 18, 2016 at 12:35 AM, gliechtenstein notifications@github.com
wrote:

@aenbacka https://github.com/aenbacka that's a great point. I think
this is a good timing to share another undocumented feature. It's called
$keys and you can actually use it right now without any code change. It
basically lets you store key/value pairs inside settings.plist and access
them from the app.

Just like rest of the undocumented features, this was intentionally left
out of the official documentation because I wasn't sure about providing
this feature from the beginning and wanted to first release and see if
people actually feel the need for this.

Here's an example of using the $keys notation:
https://jasonbase.com/things/kXz/edit

In this case we make $oauth requests (another undocumented yet extremely
powerful feature) using client_id and client_secret. If you look under
settings.plist in the Jasonette Xcode project, you'll see the two
corresponding empty fields. So it's not just client_id and client_secret,
but basically you can add any key/value pairs there and access them through
$keys notation, similar to how you use $get.

Just like you said, in this case it is necessary to protect the client_id
and client_secret so others can't them and impersonate you for oauth
requests.

But I think having a local JSON for this purpose (as a config file) may
prove to be much more powerful than using the plist format which only
supports single depth key/value pairs.

Will need to give this a serious thought.

Good catch! 👍


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#48 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0MKU_SZjRLPUoXi-4x26v8Jd2APh5aks5q_TkcgaJpZM4Kxns1
.

@aenbacka

This comment has been minimized.

Copy link

aenbacka commented Nov 18, 2016

Thanks for the replies, I think the local key-value plist solution will solve the main security issues. I think the Jasonette concept is really powerful and flexible overall.

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Nov 19, 2016

@superboonie @jdrydn sorry for the confusion, let me clarify. Currently, you can store things locally by adding keys to your settings.plist file and refer to them from JSON using {{$keys.[variable name]}} notation.

So for example, you could add a value to the client_id key in your settings.plist file, and then use it from your app via {{$keys.client_id}}.

{
  "type": "$oauth.auth",
  "options": {
    "access": {
      "client_id": "{{$keys.client_id}}",
      "client_secret": "{{$keys.client_secret}}"
    }
  }
}

However, the way that I've implemented it currently is pretty limited--this $keys notation currently only supports key/value pairs. Here's the code.

What I meant by JSON being more powerful was, assuming that we support this local JSON feature, we not only have a way to draw views locally but also can use the files as sort of a readonly local DB:

we could have a separate action fetch the JSON locally, run it through template, and use it in whichever way we want. In this case the JSON doesn't necessarily have to be a JASON markup. It can be any type of JSON.

For example:

config.json

{
  "api_keys": {
    "github": {
      "client_id": "...",
      "client_secret": "..."
    },
    "dropbox": {
      "client_id": "...",
      "client_secret": "..."
    },
    "reddit": {
      "client_id": "...",
      "client_secret": "..."
    }
  }
}

And I can imagine implementing a new action like:

{
  ...
  "actions": {
    "$load": {
      "type": "$file.open",
      "options": {
        "name": "config.json"
      },
      "success": {
        "type": "$oauth.auth",
        "options": {
          "access": {
            "client_id": "{{github.client_id}}",
            "client_secret": "{{github.client_secret}}"
          }
        }
      }
    }
  }
}

Of course, theoretically we could transform plist into JSON before running it through the template, but using JSON would be simpler. And we can have multiple files this way, whereas using settings.plist is constrained by a single file.

That said, this was not what the original thread was about. I think I went on a tangent with this. The main topic for this thread was that we can store the view JSON (JASON) locally and load it by using a local url, it's much simpler than all the sci-fi story I wrote above. Anyway at this point I think it makes sense to support this feature. Will keep you posted.

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Nov 19, 2016

We're having a conversation regarding @copongcopong 's local file implementation here: #42 (comment) Please check it out and feel free to share your thoughts.

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Dec 15, 2016

Just merged @copongcopong 's pull request here: #42

Available on develop branch.

To use:

  1. Place a JSON file anywhere under file:// folder
  2. Refer to it from settings.plist, for example file://hello.json (Note that XCode projects don't maintain file/folder hierarchy so you cannot do stuff like file://documents/hello.json. It's always file:// followed by the filename.

screen shot 2016-12-15 at 11 07 31 am

@clsource

This comment has been minimized.

Copy link
Contributor

clsource commented Mar 18, 2017

(Note that XCode projects don't maintain file/folder hierarchy so you cannot do stuff like file://documents/hello.json. It's always file:// followed by the filename.

Yes It can be done using folder references.
1.- Create a Directory
2.- Create a group named file://
3.- Click Add Files to Project
4.- Select Directory. Ensure you select create folder references
5.- Put the path including the directory and it's done.

captura de pantalla 2017-03-18 a las 2 43 33 p m

captura de pantalla 2017-03-18 a las 2 42 31 p m

👍

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Mar 19, 2017

@clsource wow i did not know that! Thanks for this, this opens a lot of doors! Need to explore this option, create an issue: #152

@kintaro1981

This comment has been minimized.

Copy link

kintaro1981 commented Jul 4, 2017

with this we can backup with offline json if no connection available? is anyone using it like this?

how about relay on offline json to cache data and then when the connection back on push that cached data to the cloud?

@gliechtenstein

This comment has been minimized.

Copy link
Contributor Author

gliechtenstein commented Jul 4, 2017

@kintaro1981 check this out. With the latest version, Jasonette now supports full offline mode in many different ways http://docs.jasonette.com/offline/

I haven't really officially announced this yet and plan to write a post on this soon, but you can find all you need in that documentation for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.