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

Refactor Code and Docs "Server" Verbiage #720

Closed
Archmonger opened this issue Mar 28, 2022 · 10 comments · Fixed by #726
Closed

Refactor Code and Docs "Server" Verbiage #720

Archmonger opened this issue Mar 28, 2022 · 10 comments · Fixed by #726
Labels
priority-3-low May be resolved one any timeline. type-docs About changes and updates to documentation type-refactor About improving code structure.
Milestone

Comments

@Archmonger
Copy link
Contributor

Current Situation

There are a lot of locations in the source & docs where we currently call things "server", when they really should be called "web frameworks"

Proposed Actions

Rename functions, comments, and docs while keeping these guidelines in mind

  • Web Framework = FastAPI, Flask, Sanic, Tornado, Django
  • Web Server = Gunicorn, Uvicorn, Hypercorn, Daphne, Built-in development servers, etc
  • Reactive Component Framework = IDOM
    • It's an easier way to distinguish us rather than the more literal "we are a web framework built on-top of web frameworks"
  • Views = Built-ins that assist in plopping something visual onto the page
  • Components = We are already pretty good about the usage of "component", no need for change
@Archmonger Archmonger added type-docs About changes and updates to documentation priority-3-low May be resolved one any timeline. type-refactor About improving code structure. labels Mar 28, 2022
@Archmonger Archmonger added this to the 2.0 milestone Mar 28, 2022
@rmorshea
Copy link
Collaborator

rmorshea commented Mar 28, 2022

I basically agree and was thinking about this in my last PR. Only difference is that maybe we could use "Web Application" instead of "Web Framework". Framework is a bit generic - in principle one can have frameworks for building both apps and servers. With that I'd probably rename idom.server to idom.app

@Archmonger
Copy link
Contributor Author

Archmonger commented Mar 28, 2022

"web application" is rough. Although it makes sense, that namespace is currently getting used up by Progressive Web Applications, so it ends up feeling incorrectly labeled.

@Archmonger
Copy link
Contributor Author

I haven't given much thought on what we could rename idom.server to.

Maybe idom.compat?

I'm currently on vacation, I'll give more thought to this next week.

@Archmonger
Copy link
Contributor Author

Archmonger commented Apr 4, 2022

I'll likely update this list if I think of more. But this is what I have for now:

  1. idom.compat
  2. idom.compatbility
  3. idom.framework
  4. idom.support
  5. idom.backend
  6. idom.conf
  7. idom.app

@rmorshea
Copy link
Collaborator

rmorshea commented Apr 4, 2022

I'm thinking idom.app might be fine. Whenever you construct something like flask.Flask or sanic.Sanic all the examples assign to an app variable.

@rmorshea
Copy link
Collaborator

rmorshea commented Apr 4, 2022

We should be able to use the same language as these app frameworks do in their documentation.

@Archmonger
Copy link
Contributor Author

Archmonger commented Apr 4, 2022

In that context, app is referring to the WSGI/ASGI application. But in our case, the end user isn't really directly interfacing with the WSGI/ASGI app through IDOM.

At the same time, I'm personally not a big fan of any of the options I posted.

I'd think of it from a few steps back. What is it that the module currently trying to do, and what might it do in the future? From my perspective:

  • Provide helper functions specific limited to our supported web frameworks
  • Provide ability to launch on a supported web framework
  • Provide scoped access to WS/HTTP contexts/requests
  • Future: Provide in-depth pre-developed framework features/hooks (ex. django-idom#33)
  • Future: Provide embedding/runtime utilities

This module really sounds like a compatibility layer to me.

@rmorshea
Copy link
Collaborator

rmorshea commented Apr 4, 2022

Besides idom.app I'd say idom.compat would be my next pick.

@rmorshea
Copy link
Collaborator

rmorshea commented Apr 4, 2022

Actually, didn't see idom.backend - that one's pretty good.

@Archmonger
Copy link
Contributor Author

Agreed. Semantically, idom.backend does make a lot of sense. I'll sit on this one for a bit and see if I think of any other options.

@Archmonger Archmonger modified the milestones: Luxury, 1.0 Jan 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-3-low May be resolved one any timeline. type-docs About changes and updates to documentation type-refactor About improving code structure.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants