search

cubehouse / themeparks

Unofficial API for accessing ride wait times and schedules for Disneyland, Disney World, Universal Studios, and many more parks
MIT License
536 stars 126 forks source link

Themeparks 6.x and the future #307

Closed cubehouse closed 2 years ago

cubehouse commented 3 years ago

Hi all,

I've finished my latest big project at work at my real job, and finally gotten some time to start attending this again.

Some thoughts I've had recently.

Discord

Would people be interested in having a small community elsewhere off GitHub where conversation is a bit easier? There are a lot of interesting discussions lost in the maze of GitHub issues, and I would be curious if people have any good ideas where that might occur more reliably?

I thought perhaps Discord, and I've setup a blank server https://discord.gg/Z7RYWDg to try out. I will park in there occasionally if anyone fancies giving it a spin and a natter.

Themeparks 6.x

Managing the library is getting more and more complex. Parks API change frequently, and I don't think deploying new NPM modules for every minor API change from one park is really the best approach now.

Instead, for 6.x, my current plan is to turn this repo into a client for a hosted solution I'll be setting up. A lot of users are using this library expecting it to work in the browser, or on serverless architecture, or easily ported to some other programming language. These are all perfectly reasonable desires, but is not what this library is meant to be doing.

However, I know some library users really like seeing the internals and exploring/fixing the codebase (or will not like how a hosted solution works), and I don't want to get in the way of that. So I'm going to start 6.x work in a separate repo that contains just the inner module for interfacing with parks to get wait times. This new repo won't store any credentials for accessing any park APIs (these will need to be sourced separately). I want to avoid any further takedown requests of the library, and I really don't think the majority of library users really care about how/where the data is coming from.

I hope this combined with a more dynamic community like Discord may get the project moving, help us reach a more stable solution and faster turn arounds on resolving issues (rather than relying on people constantly updating the npm modules).

Let me know if you have any thoughts, GitHub Issues are not a great way of gauging what everyone is thinking, but I would appreciate opinions on this approach before I start working on it.

Thank you all for your support. Every time a pull request to ThemeParks is made, a cubehouse smiles.

ImAnAutie commented 3 years ago

I would potentially be interested in a hosted API if it made interacting with this data in a serverless environment (Firebase Cloud Functions in my case easier).

Have you also considered potencially splitting it into a core library and extra modules for each park (or base APIs in the case of parks like Merlin Entertainments)?

jeanmatthieud commented 3 years ago

Hi,

I tried to join you on the discord server, but I have an "Invalid invite" error message. Does it mean that the 6.x version will not be 100% open source? I like the fact that you will be hosting a solution for easier integration, but I still want to be able to manage my own solution for my custom purposes.

cubehouse commented 3 years ago

I've updated the Discord link, hopefully that works?

The plan is to have a client library for a hosted solution, so that people who just want to get things working ASAP can do so.

But there will also be a separate repo with the source code for interacting with park APIs. However, this new repo will not contain any sensitive credentials (like API keys or passwords), they will need to be configured via script or environment variable. I will make sure this is as easy to setup as possible, hopefully through a single configuration file. This should allow the "hardcore" small group of people who want full control over the source to continue as before.

HoffiF commented 3 years ago

Sounds like an interesting idea to me. Will the client library for a hosted solution allow you to access the data via JSON?

Since I'm currently in the process of getting deeper into the whole topic of APIs. I have one question, though, API keys or passwords should not be included in the open source script. Will there be small help to get them. For example, the new app of Europa-Park & Rulantica (8.0.0), no matter what I do... I just can't get the new access data. I have been working on it for days. The EP makes it difficult & i would have little chance to get a self-hosted solution.

migo315 commented 3 years ago

For a while I offered an free API on https://coaster.cloud to query the waiting times (similar to your idea). But due uncertain legal reasons I have removed this a few weeks ago. I think it would be cool if there was an API again. I am currently also very involved in my project. But let me know if I can help.

Do you prefer an REST API, GraphQL or both?

or on serverless architecture

Well, it's not that hard with this library. I only needed a few lines of code to query and store waiting time data via AWS Lambda every 5 minutes.