Add best practices for bottom up approach #624

shimks · 2018-02-17T03:54:39Z

connected to [Docs] Polish docs for bottom-up approach loopback-next#735
initial docs proposal for adding a 'best practices' section for bottom up approach
need link to the getting-started-example once that's added into the docs

virkt25 · 2018-02-20T21:24:04Z

Haven't reviewed the entire PR but a high level question ...

Do people normally understand what is meant by top-down and bottom-up approach? It personally took me a while to remember which approach is which and even now at times I have to think about it. I think we need better names (but don't know any off the top of my head).

virkt25 · 2018-02-20T21:24:45Z

Whoops. Accidentally hit Close and comment.

shimks · 2018-02-20T21:42:14Z

I think it's ok to keep the names, but I agree on the fact that those names need clarification on what we mean by them.

React seems to be using the terms (https://reactjs.org/docs/thinking-in-react.html#step-2-build-a-static-version-in-react), but not all that often. I'd like to hear other people's thoughts on this

kjdelisle

Mostly good, just a few typos and some areas of confusion that need tidying up.

kjdelisle · 2018-02-20T21:08:54Z

pages/en/lb4/Best-practices-with-Loopback-4.md

-4. [**Implementing features**](./Implementing-features.html): This section demonstrates how the tests for each feature of your application should be written, and how to write the logic to make these tests pass. In the example, the tests for the controller, model, repository, data source, and sequence are written and then implemented.
-5. [**Preparing the API for consumption**](./Preparing-the-API-for-consumption.html): This section shows how the endpoints can be physically tested using the Swagger UI.
+1. **Defining the API**: There are two possible approaches to take in this section
+  - [**Defining the API using bottom-up appraoch**](./Defining-the-API-using-bottom-up-approach.html): This section guides you through setting up a skeleton of your application so that a full API can be automatically generated.


Typo in approach

Not sure what you mean by so that a full API can be automatically generated; the bottom-up approach is one where you're building the controllers, functions, routes and so on that make up the bulk of your API. The portion that's generated is the OpenAPI/Swagger specification that describes it.

kjdelisle · 2018-02-20T21:11:14Z

pages/en/lb4/Best-practices-with-Loopback-4.md

-5. [**Preparing the API for consumption**](./Preparing-the-API-for-consumption.html): This section shows how the endpoints can be physically tested using the Swagger UI.
+1. **Defining the API**: There are two possible approaches to take in this section
+  - [**Defining the API using bottom-up appraoch**](./Defining-the-API-using-bottom-up-approach.html): This section guides you through setting up a skeleton of your application so that a full API can be automatically generated.
+  - [**Defining the API using top-down approach**](./Defining-the-API-using-top-down-approach.html): This section guides you through constructing your API first before any internal logic is added.


Please follow the convention established by @b-admike 's PRs and mark this with a warning or indicator that says this approach is not yet functional/viable.

I think the warning on the page is sufficient, since they will click the links and be redirected there. But if we can do it here as well, then I'm fine with it.

kjdelisle · 2018-02-20T21:17:51Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+
+Your models will be used to provide schemas to validate against the data
+your API will intercept and consequently are likely to be referenced as
+argument types in your controllers, so they should be the first to be defined.


Your models are not necessarily going to be used to validate anything. I can easily write my controller functions to accept objects that are neither strictly nor logically equivalent to my model objects.

The value of using models is that they give you a common, workable definition for:

representing inbound and outbound data at the API layer

handling data and relationships at the datasource layer

Intercept carries a very particular connotation; that the intended recipient is not the first to receive or act upon the incoming payload. In our case, we're not intercepting the request, we're handling it.

kjdelisle · 2018-02-20T21:18:45Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+```
+
+This model is just a TypeScript class without any decorators in its current
+form, so features such as automatic schema generation are not available to it


This is just filler. It's more than adequate to say that this is just a plain TypeScript class.

kjdelisle · 2018-02-20T21:23:26Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+form, so features such as automatic schema generation are not available to it
+yet.
+
+Now decorate the class with `@model` and `@property`.


Explain what these decorators accomplish in the same sentence/paragraph here.

We can use the @model and @property decorators to create _metadata_ that represents the model; a model definition. LoopBack and LoopBack extensions can use this model definition for a wide variety of uses, such as: - generating OpenAPI schema for your APIs - validating instances of the models during the request/response lifecycle - automatically inferring relationships between models during datasource operations To apply these decorators to your model, you simply prefix the class definition with the @model decorator, and prefix each property with the @property decorator:

kjdelisle · 2018-02-20T21:30:41Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+The controller's routes in their current state has no information on which
+API endpoints they belong to. Add them in by using `@operation` and `@param`
+decorators.
+


There should be a tag here to indicate the name of this example file.
{% include code-caption.html content="src/todo.controller.ts" %}

kjdelisle · 2018-02-20T21:31:04Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+for each categories of your API.
+
+```ts
+class TodoController {


kjdelisle · 2018-02-20T21:31:08Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+decorators.
+
+```ts
+class TodoController {


kjdelisle · 2018-02-20T21:40:09Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+its API; when an instance of `RestServer` is run, an OpenAPI specification
+representing your application's API is built. The spec is generated
+entirely from the decorated elements' metadata, which in turn provides
+routing logic for your API when your application is running.


kjdelisle · 2018-02-20T21:47:50Z

pages/en/lb4/Testing-the-API.md

@@ -9,7 +9,7 @@ summary:
 ---

 {% include previous.html content="
-This article continues off from [Defining and validating the API](./Defining-and-validating-the-API.html).
+This article continues off from [Defining the API using top-down approach](./Defining-the-API-using-top-down-approach.html).


continues from

b-admike · 2018-02-21T15:16:56Z

pages/en/lb4/Best-practices-with-Loopback-4.md

-5. [**Preparing the API for consumption**](./Preparing-the-API-for-consumption.html): This section shows how the endpoints can be physically tested using the Swagger UI.
+1. **Defining the API**: There are two possible approaches to take in this section
+  - [**Defining the API using bottom-up appraoch**](./Defining-the-API-using-bottom-up-approach.html): This section guides you through setting up a skeleton of your application so that a full API can be automatically generated.
+  - [**Defining the API using top-down approach**](./Defining-the-API-using-top-down-approach.html): This section guides you through constructing your API first before any internal logic is added.


I think the warning on the page is sufficient, since they will click the links and be redirected there. But if we can do it here as well, then I'm fine with it.

b-admike · 2018-02-21T15:34:43Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+" %}
+
+Once your models are defined, create a controller to host your routes
+for each categories of your API.


I'd say for each [Paths object](https://swagger.io/specification/#pathsObject) of your API specification here.

b-admike · 2018-02-21T15:36:18Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+class TodoController {
+  constructor() {}
+
+  @post('/todo') // sugar for @operation('post', '/todo');


not sure if people would know what sugar means, so I suggest you rephrase as same as @operation('post', '/todo');

b-admike · 2018-02-21T15:41:15Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+### Reviewing your API specification
+
+To review your complete API specification, run your application with the
+decorated controllers registered. Once it is running, visit `/swagger.json`


They can also go to openapi.json to get OpenAPI 3.0 spec and .yaml for both to get them in yaml flavour.

I want to leave it at just swagger for now since we don't support OpenAPI v3 yet, but I'll add in short sentence saying that yaml flavour is also available. I'll leave it up to Janny to fix the swagger to openapi related doc switch-overs when she's doing her docs.

raymondfeng · 2018-02-21T16:54:46Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+
+Sometimes, it's hard to know what your API is going to look like without
+writing out your application first. It also might be difficult to adjust your
+API as plans change or as features need to be reworked.


IMO, the reasoning for bottom-up is misleading here. Please rewrite it to align with some ideas below:

Designing APIs in vacuum is not only difficult but also not wise if you don't have a good understanding of what your existing system can offer and what your clients need.

Bottom-up approach allows developers to capture existing business domain models and corresponding operations and reflect them for external consumption as APIs. Such information can be defined as metadata with code, JSON/YAML documents, or decorations.

Bottom-up approach better aligns APIs with implementations from the beginning and evolve them all together as API consumers and providers reach agreements incrementally.

Bottom-up approach makes it possible to have APIs up and running for play and polish at very early stages, which is critical to the success of APIs as stakeholders can see the big picture collaboratively before it's too late.

b-admike · 2018-02-22T13:50:59Z

pages/en/lb4/Defining-the-API-using-bottom-up-approach.md

+easily envision the big picture of the end product.
+
+There are various tools available to LoopBack which allows this bottom-up
+approach of building your application simple through the usages of


simple -> simply

b-admike · 2018-02-22T14:35:02Z

In terms of what to name the sections, how about code first application design vs API first application design or something along those lines?

bajtos · 2018-02-26T11:56:46Z

The new content in Defining-the-API-using-code-first-approach.md does not say anything about testing your new application. Originally, Thinking in LoopBack was heavily focused on showing people how to write application in test-first/test-driven style. It would be great to preserve this spirit for code-first approach too.

shimks · 2018-02-28T16:27:39Z

@bajtos Could you be more specific as to what you're envisioning? The code in Defining-the-API-using-code-first-approach.md contains no logic, so do you mean that I should show a skeleton of the endpoints that I need to test out for the controller?

virkt25 · 2018-02-28T18:39:31Z

_data/sidebars/lb4_sidebar.yml

@@ -103,13 +103,18 @@ children:
  output: 'web, pdf'
  children:

-  - title: 'Defining and validating the API'
-    url: Defining-and-validating-the-API.html
+  - title: 'Defining the API using code-first approach'


Defining API's using code-first approach might be better. Defining the API ... seems odd.

+1. As a helpful comment though, ~~never~~ try not to use 's to make something plural :p, even for acronyms (unless it ends with an S, then I have no clue lol).

virkt25 · 2018-02-28T18:39:46Z

_data/sidebars/lb4_sidebar.yml

    output: 'web, pdf'

-  - title: 'Testing the API'
-    url: Testing-the-API.html
+  - title: 'Defining the API using API-first approach'


virkt25 · 2018-02-28T18:40:05Z

_data/sidebars/lb4_sidebar.yml

    output: 'web, pdf'
+    children:
+
+    - title: 'Testing the API'


Testing API's ... ?

virkt25 · 2018-02-28T18:46:39Z

pages/en/lb4/Best-practices-with-Loopback-4.md

+1. **Defining the API**: There are two possible approaches to take in this section
+   - [**Defining the API using code-first approach**](./Defining-the-API-using-code-first-approach.html): This section guides you through setting up a skeleton of your application so that its full OpenAPI specification can be automatically generated.
+   - [**Defining the API using API-first approach**](./Defining-the-API-using-API-first-approach.html): This section guides you through constructing your API first before any internal logic is added. __*Not fully supported*__
+     - [**Testing the API**](./Testing-the-API.html): This section describes the process of writing smoke test for your API and its spec. __*Not fully supported*__


Shouldn't this be under Defining your testing strategy?

Back when I worked on breaking up the Thinking in LoopBack page, the rough structure of the page went from:

Define your API

Test your API

Summary of TTD

Writing your code using TTD

To me testing the app is different from testing the API (spec), and it makes sense to me that when you're using the build-your-API-spec-first approach you would go about testing the API (in the form of openapi spec) first before you test anything that has to do with the application.

bajtos · 2018-03-01T14:40:44Z

Could you be more specific as to what you're envisioning? The code in Defining-the-API-using-code-first-approach.md contains no logic, so do you mean that I should show a skeleton of the endpoints that I need to test out for the controller?

Right now, your narrative is "Define your models", "Define your routes", "Reviewing your API specification". That's not how test-first people work! Take a look at Incrementally implement features to see test-first approach in work for top-down approach.

For the documention of code-first approach, I would like to see a similar content/narrative:

Pick one (and only one!) endpoint you are going to implement.
Start with an acceptance test describing endpoint's behaviour (see Write an acceptance test). This acceptance test is going to server as an indicator telling you when you are done with this endpoint.
Write a unit-test for the new controller method you are going to implement (see Write a unit-test for the new controller method, this section contains an example of the actual controller implementation at the bottom.)
Write the first implementation of the controller method to make the test pass. This is time to put code-first approach in work, e.g. use REST decorators like @get and @param.
Write an integration test to verify that the controller is using data from the database (see Write an integration test for the new controller method
Now comes the best time for defining models & repositories - see Define Product model, repository, and data source. Because you are describing bottom-up approach, I think it's acceptable to assume that our data/repository/model layer is already set up and/or was configured before we started writing controllers for the REST API. This configuration should still be implemented in test-first way though!
Update test helpers and the controller use real model and repository
Run the tests again and fix the issues - see Run tests
Decouple controller from Repository
Handle 'product not found' error

Basically I am asking you to create a guide that's similar to what we have for bottom-down approach, but with specific details changed to accommodate the bottom-up (code-first) approach.

If there are sections that can or should be reused by both guides, then it may be worth extracting them into shared content. (I don't know how easy it is, or whether it's feasible at all.)

For example, the last step in the api-first guide, Implement a custom sequence, should be pretty easy to extract into a standalone document that both code-first and api-first guide can refer to.

I am not sure what's the exact scope of your task (the user story you are working on). If a guide as I described above is beyond the scope, then I can live with the shorter version you proposed here and will open a new issue to bring the code-first guide up to the level of the api-first guide. Please let me know!

shimks · 2018-03-01T15:03:16Z

Thanks for a very detailed narrative @bajtos ! Considering that @kjdelisle is working on the tutorial story (loopbackio/loopback-next#729), I personally thought the story I'm working on (loopbackio/loopback-next#735) would serve to merely accompany the Defining and validating the API page with the bottom-up approach. It seems like the narrative you proposed requires the docs I'm writing to be essentially an extension piece of example-getting-started that shows how the tutorial is written the test-first approach.

Right now I'm thinking that I rewrite this section as an extension piece of the tutorial, continuing off from https://github.com/strongloop/loopback-next/blob/master/packages/example-getting-started/docs/6-repository.md. From there I'm thinking of following your proposed content structure to finish off example-getting-started application with complete tests to go with it. Does this sound good to you?

bajtos · 2018-03-01T15:15:53Z

merely accompany the Defining and validating the API page with the bottom-up approach.

I see. I quickly checked the content in Defining and validating the API, I agree your current content is closer to that page than my long proposal, which makes more sense in the context of your task.

So maybe it's enough if you add notes to your existing content to tell people that the examples in your content are just showing how to define API and pointing them to "Incrementally implement features" for better examples showing the implementation process including test coverage?

Right now I'm thinking that I rewrite this section as an extension piece of the tutorial, continuing off from https://github.com/strongloop/loopback-next/blob/master/packages/example-getting-started/docs/6-repository.md. From there I'm thinking of following your proposed content structure to finish off example-getting-started application with complete tests to go with it. Does this sound good to you?

Sounds reasonable to me. I think it may be best to split the work into two (or more) pull requests, the first one covering "I rewrite this section as an extension piece of the tutorial", so that we can land something sooner than later?

shimks · 2018-03-01T15:37:00Z

I think it may be best to split the work into two (or more) pull requests, the first one covering "I rewrite this section as an extension piece of the tutorial", so that we can land something sooner than later?

Could you clarify how I could go about breaking up the work into multiple pull requests? Are you thinking that the first PR to be less detailed than what it should be? Or do you mean I should break up the actual contents in chunks that resembles something like this ?:
acceptance test -> unit test -> write logic -> integration test -> update tests/code -> tahdah you're done!!!

bajtos · 2018-03-02T12:54:48Z

Could you clarify how I could go about breaking up the work into multiple pull requests? Are you thinking that the first PR to be less detailed than what it should be?

As I was reading your comment, it occurred to me that your plan seems to have two distinctive parts/tasks:

Right now I'm thinking that I rewrite this section as an extension piece of the tutorial, continuing off from https://github.com/strongloop/loopback-next/blob/master/packages/example-getting-started/docs/6-repository.md. From there I'm thinking of following your proposed content structure to finish off example-getting-started application with complete tests to go with it. Does this sound good to you?

I was thinking:

pull request 1: rewrite this section as an extension piece of the tutorial, continuing off from https://github.com/strongloop/loopback-next/blob/master/packages/example-getting-started/docs/6-repository.md
pull request 2 (3, 4, etc.): From there I'm thinking of following your proposed content structure to finish off example-getting-started application with complete tests to go with it.

Just an idea to consider. Please organize your work and pull requests in a way that works best for you!

bajtos · 2018-03-02T13:14:57Z

@shimks I think we should find a smaller scope for your work, considering the description in loopbackio/loopback-next#735:

Add a new page at the same level, something like "Define your API bottom-up way". Explain basic concepts (controller decorators like @post, @param etc.) and point people to example-getting-started as the tutorial.

The outline described in #624 (comment) may require more effort that we have planned for this task. Could you please talk to @kjdelisle to find a good balance between the ideal I described and the MVP/Walking Skeleton scope.

kjdelisle

In all cases, we're defining an application, not an API. The API is a part of the application (since it's what consumers will use), but the phrasing on a lot of the top-down methods is wobbly if you refer to the whole app as an API.

kjdelisle · 2018-03-02T17:14:37Z

pages/en/lb4/Best-practices-with-Loopback-4.md

-5. [**Preparing the API for consumption**](./Preparing-the-API-for-consumption.html): This section shows how the endpoints can be physically tested using the Swagger UI.
+1. **Defining the API**: There are two possible approaches to take in this section
+   - [**Defining the API using code-first approach**](./Defining-the-API-using-code-first-approach.html): This section guides you through setting up a skeleton of your application so that its full OpenAPI specification can be automatically generated.
+   - [**Defining the API using API-first approach**](./Defining-the-API-using-API-first-approach.html): This section guides you through constructing your API first before any internal logic is added. __*Not fully supported*__


I'd rephrase this bit to say "Defining your app using the API-first approach" or something similar.
"Defining the API using API-first approach" sounds a bit like saying "Making your app by using the app-first approach" :P

kjdelisle · 2018-03-02T17:15:00Z

pages/en/lb4/Defining-the-API-using-API-first-approach.md

@@ -13,7 +13,7 @@ page are outdated and may not work out of the box. They will be revisited after
 our MVP release.
 "%}

-## Define the API
+## Define the API from top to bottom (API-first)


Define the app from top to bottom

raymondfeng · 2018-03-05T17:46:09Z

_data/sidebars/lb4_sidebar.yml

-  - title: 'Testing the API'
-    url: Testing-the-API.html
+  - title: 'Defining the app using API-first approach'
+    url: Defining-the-app-using-API-first-approach.html


What about Design First vs. Code First? See https://swaggerhub.com/blog/api-design/design-first-or-code-first-api-development/

jannyHou

LGTM 👍

b-admike · 2018-03-09T16:32:27Z

pages/en/lb4/Defining-the-API-using-code-first-approach.md

+### Reviewing your API specification
+
+To review your complete API specification, run your application with the
+decorated controllers registered. Once it is running, visit `/swagger.json`


/openapi.json

bschrammIBM

I will need to copyedit this doc after it is posted due to time constraints with Velox.

shimks requested a review from bschrammIBM as a code owner February 17, 2018 03:54

shimks added the needs-priority label Feb 17, 2018

virkt25 closed this Feb 20, 2018

virkt25 removed the needs-priority label Feb 20, 2018

virkt25 reopened this Feb 20, 2018

virkt25 added the needs-priority label Feb 20, 2018

kjdelisle suggested changes Feb 20, 2018

View reviewed changes

shimks force-pushed the bottom-up-doc branch from f8c7347 to 0cb24e3 Compare February 20, 2018 22:54

b-admike reviewed Feb 21, 2018

View reviewed changes

raymondfeng reviewed Feb 21, 2018

View reviewed changes

shimks force-pushed the bottom-up-doc branch 2 times, most recently from 21bb5b1 to 9ed1d01 Compare February 21, 2018 21:44

b-admike reviewed Feb 22, 2018

View reviewed changes

shimks force-pushed the bottom-up-doc branch from 72a90b1 to 18998ff Compare February 22, 2018 16:31

b-admike approved these changes Feb 23, 2018

View reviewed changes

shimks force-pushed the bottom-up-doc branch from 18998ff to ffa8365 Compare February 23, 2018 19:41

dhmlau mentioned this pull request Feb 23, 2018

[Docs] Polish docs for bottom-up approach loopbackio/loopback-next#735

Closed

4 tasks

virkt25 reviewed Feb 28, 2018

View reviewed changes

shimks force-pushed the bottom-up-doc branch from ffa8365 to c3b72b2 Compare March 1, 2018 16:26

kjdelisle suggested changes Mar 2, 2018

View reviewed changes

shimks changed the title ~~[WIP] Add best practices for bottom up approach~~ Add best practices for bottom up approach Mar 5, 2018

shimks force-pushed the bottom-up-doc branch 2 times, most recently from dfdf921 to 873e8d3 Compare March 5, 2018 16:31

raymondfeng reviewed Mar 5, 2018

View reviewed changes

jannyHou approved these changes Mar 5, 2018

View reviewed changes

b-admike reviewed Mar 9, 2018

View reviewed changes

shimks added 7 commits March 9, 2018 15:19

add best practices for bottom up

0a2555f

apply feedback

29499ac

add tutorial links

adae173

change titles of bottom-up top-down

5fae1c4

change defining-the-api to -app

c37259c

change to design-first

6f38886

switch to openapi-v3

2e52996

shimks force-pushed the bottom-up-doc branch from c3d87b4 to 2e52996 Compare March 9, 2018 20:21

bschrammIBM approved these changes Mar 9, 2018

View reviewed changes

shimks merged commit 02ac72e into gh-pages Mar 9, 2018

shimks deleted the bottom-up-doc branch March 9, 2018 20:53

shimks removed the needs-priority label Mar 9, 2018

This was referenced Mar 15, 2018

Docs/finish migration from loopback.io loopbackio/loopback-next#1141

Merged

Clean up "Best Practices with LoopBack 4" loopbackio/loopback-next#1094

Closed

Add best practices for bottom up approach #624

Add best practices for bottom up approach #624

Conversation

shimks commented Feb 17, 2018

virkt25 commented Feb 20, 2018

virkt25 commented Feb 20, 2018

shimks commented Feb 20, 2018

kjdelisle left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kjdelisle Feb 20, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

b-admike commented Feb 22, 2018

bajtos commented Feb 26, 2018

shimks commented Feb 28, 2018

Choose a reason for hiding this comment

shimks Mar 1, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bajtos commented Mar 1, 2018

shimks commented Mar 1, 2018 • edited

bajtos commented Mar 1, 2018

shimks commented Mar 1, 2018 • edited

bajtos commented Mar 2, 2018

bajtos commented Mar 2, 2018

kjdelisle left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raymondfeng Mar 5, 2018 • edited

Choose a reason for hiding this comment

jannyHou left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bschrammIBM left a comment

Choose a reason for hiding this comment

kjdelisle Feb 20, 2018 •

edited

shimks Mar 1, 2018 •

edited

shimks commented Mar 1, 2018 •

edited

shimks commented Mar 1, 2018 •

edited

raymondfeng Mar 5, 2018 •

edited

jannyHou left a comment •

edited